[01:36] <BenC> that's funny
[01:37] <BenC> that "frenzy" happened about 30 minutes from where I live
[01:37] <BenC> crazy rednecks
[01:47] <dilinger> haha
[06:22] <fabbione> morning
[06:22] <desrt> :D
[06:22] <desrt> welcome back, dude
[06:22] <fabbione> desrt: I HATE YOU ALL! I WANT TO GO BACK IN HOLIDAYS!
[06:22] <desrt> woh
[06:22] <fabbione> ;)
[06:22] <desrt> sounds like you could really use another week or two :P
[06:23] <fabbione> easily...
[06:23] <desrt> anyway.. i was hacking yaboot on the weekend
[06:23] <desrt> as it is, breezy won't boot on an xserve unless it has a videocard
[06:23] <fabbione> hmmm
[06:23] <desrt> i have a fix
[06:24] <desrt> but......
[06:24] <fabbione> but?
[06:24] <desrt> it disables the stage 1 yaboot menu
[06:24] <desrt> ie: it just loads stage 2 directly
[06:24] <desrt> (stage1 is the part that has a problem)
[06:24] <fabbione> i don't think that's a solution
[06:24] <desrt> well, it is for me :)
[06:24] <fabbione> yeah for you...
[06:24] <desrt> it's only a problem if you have multiple OSes installed (macos dualboot)
[06:24] <desrt> i'm working on generalising the code
[06:25] <desrt> but work has been a bit hectic the past week
[06:25] <desrt> + i don't know forth :)
[07:08] <fabbione> BenC: still awake?
[07:26] <infinity> Gar, is there something mind-numblingly obvious I'm missing, or is the kernel bridging interface really such utter shit?
[07:26] <infinity> When I unplug a cable from one of the bridged interfaces, the whole bridge goes down.  YAY.
[07:26] <infinity> (Or power cycle the system it's plugged into, or whatever)
[07:27] <fabbione> eth brinding?
[07:27] <fabbione> that shouldn't happen
[07:27] <infinity> ethernet, yes.  When one interface loses linkbeat, the bridge dies.
[07:27] <fabbione> are you sure you have no userland tools checking via mii that the iface is connected to a cable?
[07:28] <infinity> (Doesn't actually down the interface, just stops relaying packets, even after the linkbeat comes back)
[07:28] <infinity> Oh, it's possible.  THe bridge is on a breezy desktop, so there might be some irritating magic going on.
[07:28] <fabbione> becasue i use brindging on 2.4 on a dead iface to talk to xen domains
[07:28] <infinity> Though I can't think of what (no, network-manager isn't installed)
[07:28] <fabbione> infinity: try to do it in single user mode to see if it is userland?
[07:33] <desrt> this is completely and totally awesome
[07:35] <fabbione> desrt: what?
[07:35] <desrt> excuse the paste
[07:35] <desrt> 0 > boot hd:2,\\yaboot load-size=24830 adler32=ad6b4eba
[07:35] <desrt> Loading ELF
[07:35] <desrt> Config file read, 678 bytes
[07:35] <desrt> Welcome to yaboot version 1.3.13
[07:35] <desrt> Enter "help" to get some basic usage information
[07:35] <desrt> boot:
[07:35] <desrt>   Linux                      old
[07:35] <desrt> boot: Linux
[07:35] <desrt> Please wait, loading kernel...
[07:35] <desrt>    Elf32 kernel loaded...
[07:35] <desrt> Loading ramdisk...
[07:35] <desrt> i can interact with openfirmware (and yaboot) using a whole bunch of methods
[07:36] <desrt> including -telnet-
[07:36] <fabbione> yeah i knew that OF has telnetd
[07:36] <desrt> that's awesome!
[07:36] <desrt> like, crikey!
[07:36] <fabbione> infinity: ask svenl for upgrades :)
[07:37] <infinity> You think he'll swing me a dual G5 to replace my G3? :)
[07:37] <fabbione> i meant software..
[07:37] <fabbione> and join the queue for g5's ;)
[07:38] <infinity> Software's a no-go.  You can't update the firmware on the Beige G3 past version 2.4 (which I have)
[07:38] <infinity> OF didn't start sucking less until 3.0 (NewWorld), though.
[07:39] <fabbione> i need to hook me up with a nice toy
[07:39] <fabbione> probably i will soon get money for a new machine
[07:39] <fabbione> and i don't want it to be i386
[07:39] <fabbione> either ppc or amd64
[07:39] <fabbione> not sure yet
[07:39] <infinity> I like my amd64.
[07:39] <infinity> And my ppc, for that matter.
[07:39] <fabbione> or replace my server with a couple of sparcs
[07:40] <fabbione> OR
[07:41] <fabbione> make my workstation a new server
[07:41] <fabbione> and buy a new workstation
[07:44] <Mithrandir> amd64 is teh love.
[07:44] <fabbione> yeah i know..
[07:46] <Mithrandir> and hi and good morning and stuff
[07:58] <fabbione> hmmm
[07:58] <fabbione> what's a good brand of ATA harddisks by now?
[07:59] <fabbione> i have the following options: Maxtor, Seagate, WD 
[07:59] <calc> seagate seems good and iirc has 5 year warranty
[08:00] <calc> i want my next system to be an amd64 mac mini
[08:00] <fabbione> calc: i am looking for 4x300GB harddisk to replace my server
[08:00] <fabbione> instead of the 8x120GB that i have now
[08:01] <calc> maxtor/wd have shorter warranties iirc so seagate is likely the most reliable as well
[08:01] <fabbione> Maxtor has 16MB of cache compared to the 8Mb of the others..
[08:01] <calc> and the seagate 7200.8 series goes up to 500gb
[08:01] <fabbione> WD has 320GB instead of 300 of the others...
[08:02] <fabbione> calc: i am looking at what's available around :)
[08:02] <fabbione> at least on local hw shops
[08:02] <calc> oh
[08:02] <calc> seagate 400gb seems to be generally available so they may have that also
[08:03] <fabbione> OH right
[08:03] <fabbione> they are 2 lines below
[08:03] <fabbione> they are double as expensive as the 300GB
[08:03] <calc> i see 7200.8 400gb for sale via pricewatch already not sure if regular stores will have that yet
[08:04] <calc> heh
[08:04] <calc> yea i see 300gb seagate for $152 and 400gb for $230 on pricewatch which is still a bit expensive
[08:05] <calc> oh yea the seagate sata drives do ncq as well, not sure about maxtor/wd
[08:05] <fabbione> IMPRESSIVE
[08:05] <fabbione> they are selling Apple.. they didn't use to
[08:08] <fabbione> Mithrandir: what's a good SATA controller?
[08:12] <fabbione> given the minimum differnce in price for the hd, it might be worth making the array SATA
[09:30] <Mithrandir> fabbione: I've actually good experiences with the sii3114
[09:43] <Mithrandir> fabbione: do you have a kernel for me?
[09:46] <fabbione> Mithrandir: Herbert is working on it
[09:46] <Mithrandir> ok, cheers
[10:00] <fabbione> jbailey: i managed to fix klibc on sparc64.. 
[10:23] <fabbione> Mithrandir: is the sii from 3ware?
[10:23] <Mithrandir> no, silicon image
[10:23] <fabbione> ok
[10:24] <fabbione> of course my hw pusher doesn't have it
[10:24] <Mithrandir> it's often onboard.
[10:24] <fabbione> ah ok..
[10:24] <Mithrandir> and it's the chip name
[10:24] <Mithrandir> http://www.hwb.no/artikkel/15307
[10:24] <Mithrandir> has a test of different controllers.
[10:24] <fabbione> i am looking for a PCI card
[10:26] <fabbione> the 3ware they have is the same as in that pic :)
[10:28] <Mithrandir> well, read the article.  It's fairly decent.
[10:28] <fabbione> Kjernen benyttet under testingen var 2.6.8.1-5-amd64-k8-smp. Det ble brukt x86_64-versjonen av Warty.
[10:28] <Mithrandir> you can read norwegian well enough, can't you?
[10:28] <fabbione> yeah i think so :)
[10:31] <fabbione> well it's a lot of benchmarks
[10:31] <fabbione> but tbh i am not too interested into speed...
[10:31] <fabbione> more about: "It works in Linux,, it doesn't work"
[10:32] <Mithrandir> all of the controllers there work in Linux, obviously. :-P
[10:32] <fabbione> yeah clearly :)
[10:34] <fabbione> looking at the graphs, it makes me wish to buy SCSI :)
[10:35] <Mithrandir> there's a SCSI controller in there as well
[10:35] <fabbione> yeah.. that's why :)
[10:49] <doko> fabbione: the 3ware's are fine controllers, but spend the extra money for the 9500
[10:56] <fabbione> doko: yeah.. it also costs a fortune :)
[11:00] <infinity> Adaptec's 2410 isn't so bad. (or 2810 if you need 8 ports)
[11:01] <infinity> I'd push the 3ware stuff if money was no object, but they are very pricey.
[11:05] <fabbione> yeah
[11:05] <fabbione> but given that it's one time expense.. i guess i can look into 3ware too
[01:57] <mjg59> fabbione: I have ACPI fixup patches for you. Shall I just email a tarball with justification?
[02:00] <fabbione> mjg59: that would do
[02:02] <mjg59> fabbione: Ok, cool
[02:04] <fabbione> mjg59: from now on, please start to CC BenC 
[02:05] <fabbione> he will take over the kernel soon..
[02:06] <mjg59> fabbione: Will do
[02:06] <mjg59> fabbione: benc@canonical.com?
[02:07] <fabbione> mjg59: meh.. hold on..
[02:07] <fabbione> ben.collins@ubuntu.com
[02:07] <mjg59> Ok
[02:39] <mjg59> fabbione: Mailed
[02:40] <fabbione> mjg59: ok
[02:40] <fabbione> you gotta be kidding...
[02:40] <fabbione> 300KB of tar.gz?????
[02:41] <mjg59> fabbione: Most of that's a replacement for the existing acpi update patch
[02:42] <fabbione> ok
[02:43] <fabbione> mjg59: want to take a look at bugzilla and start marking bugs as pending upload?
[02:43] <mjg59> fabbione: Sure, will do
[02:45] <fabbione> jbailey: ping?
[02:45] <jbailey> fabbione: pong
[02:45] <fabbione> jbailey: did you like the klibc upload?
[02:46] <jbailey> I saw that it had been done, but it's just coming down now. =)
[02:46] <fabbione> nothing too fancy..
[02:46] <fabbione> change the B-D for new kernel headers
[02:46] <fabbione> added a specific sparc64 patch to fix FTBFS
[02:47] <fabbione> that doesn't touch any of the other code
[02:47] <fabbione> so pretty safe
[02:54] <mjg59> fabbione: The patch in 11813 ought to be applied
[02:56] <fabbione> OH DAMN SHIT
[02:57] <fabbione> there is no connectivity with uk toady
[02:57] <fabbione> like yesterday
[02:57] <fabbione> ok.. it's taking ages...
[02:57] <fabbione> mjg59: i need to take my wife to the doc and i will be back in about 2 hours or so
[02:57] <fabbione> probably more...
[02:57] <fabbione> just create a list and mail it..
[02:58] <fabbione> or whatever you prefer..
[02:58] <fabbione> just don't leave the list here on IRC :)
[02:59] <mjg59> fabbione: No problem
[02:59] <fabbione> thanks
[03:21] <jbailey> fabbione: Looks good, thanks.
[03:42] <fabbione> i think nobody noticed before, because klibc was probably built on sparc32 or so
[03:42] <fabbione> that's what come up to mind now..
[03:42] <fabbione> but we don't care to build in 32 bit
[03:43] <fabbione> given that: A) we don't support 32bit b) it's all used once at boot and trashed away
[03:43] <fabbione> anyway.. time to go
[03:43] <fabbione> bbl
[06:01] <fabbione> re
[06:02] <fabbione> BenC: ping?
[06:05] <fabbione> mjg59: i got the patches..
[06:05] <mjg59> fabbione: Rock
[06:08] <fabbione> mjg59: are all the patches done to be applied at the end of 00list?
[06:08] <fabbione> with the order you gave.. or somewhere else?
[06:08] <mjg59> fabbione: Which ones? The first batch or the second batch?
[06:09] <fabbione> both...
[06:09] <mjg59> The second batch should all go after the first batch, but the order doesn't matter
[06:09] <mjg59> The first batch should have the big patch first, followed by acpi-revert-pci-interrupt-resume
[06:10] <fabbione> ok
[06:10] <fabbione> than all the others in no special order...
[06:10] <mjg59> Yeah
[06:10] <fabbione> ok
[06:11] <mjg59> The others all depend on the first two, but other than that are order independent
[06:11] <fabbione> ok
[06:13] <fabbione> on which arches did you test them?
[06:13] <fabbione> do they build on ia64?
[06:13] <mjg59> Tested on x86
[06:13] <fabbione> what about amd64?
[06:13] <mjg59> I don't have access to any ia64
[06:14] <mjg59> I'll check amd64 now
[06:14] <fabbione> ok.. do you don't know if they build on amd64/ia64...
[06:14] <fabbione> try to be around tomorrow than
[06:14] <fabbione> if you can
[06:14] <fabbione> i will start merging now
[06:14] <fabbione> but i will build tomorrow probably...
[06:15] <mjg59> Sure, no problem
[06:15] <mjg59> fabbione: Oh, one thing I forgot to mention - the acpi-i2c one adds a new config option
[06:15] <fabbione> i saw that
[06:16] <mjg59> Ok
[06:16] <fabbione> i guess M is fine...
[06:16] <mjg59> Yup
[06:16] <fabbione> perfect
[06:17] <fabbione> hmmm agp-pm...
[06:17] <fabbione> didn't we include that one already?
[06:17] <mjg59> I don't think so
[06:18] <fabbione>   * Add PCI-E suspend/resume support:
[06:18] <fabbione>     - Add patch drivers-pci-pcie_resume-pcie.dpatch.
[06:18] <fabbione> no
[06:18] <fabbione> it was the PCI-E
[06:18] <mjg59> Yeah
[06:21] <fabbione> mjg59: where all these patches are coming from?
[06:21] <fabbione> just to annotate them properly...
[06:22] <mjg59> fabbione: The acpi ones are all from acpi upstream, except for the ones that we were already carrying
[06:22] <mjg59> toshiba-acpi-dev is from John Belmonte's website
[06:22] <mjg59> agp-pm is from the suspend2 tarball (which contains no indication of who wrote it)
[06:23] <mjg59> acpi-i2c is from Bruno Ducrot's website
[06:23] <mjg59> The reboot patch is me
[06:24] <fabbione> ok
[06:56] <fabbione> mjg59: only 4 left to apply :)
[06:57] <mjg59> fabbione: Woo!
[06:57] <mjg59> fabbione: I've got another couple for you...
[06:57] <mjg59> (But then that's it for the day)
[06:58] <jbailey> mjg59: At some point when you have t ime, can I get you to look over the DSDT patch that I've got to see why the classic initrd case fails?
[06:58] <mjg59> jbailey: I can have a go, yeah
[06:58] <fabbione> mjg59: send me...
[06:58] <jbailey> mjg59: Either that or do you think I can get rid of that case an only handle having a DSDT.aml file in the initramfs?
[06:58] <jbailey> the initramfs case works.
[06:58] <mjg59> Breezy is going with initramfs?
[06:58] <fabbione> mjg59: we already switched
[06:58] <jbailey> mjg59: Yes, it's default already. =)
[06:59] <mjg59> Yeah. I'd drop the initrd support, then.
[06:59] <jbailey> mjg59: Nice, saves much trouble. =)
[06:59] <jbailey> That's the part of the patch I'm having trouble with.
[07:02] <fabbione> applying patch external-drivers-acpi-hardware-hwsleep_gpe-specs to ./ ... failed.
[07:03] <mjg59> Oops
[07:03] <mjg59> That's odd
[07:04] <mjg59> Oh, shit
[07:04] <mjg59> Sorry, I accidently diffed it from the wrong directory level
[07:04] <mjg59> Looked like drivers-acpi-sleep-main_make-system-ready-to-resume.dpatch has the same problem
[07:10] <mjg59> fabbione: Ok, that's it for now
[07:11] <fabbione> mjg59: ok.. everything applies perfectly
[07:12] <fabbione> mjg59: got the last mail
[07:12] <mjg59> Rock
[07:15] <fabbione> mjg59, BenC: i am going to commit the all ACPI stuff untested
[07:15] <fabbione> i only know it applies clean
[07:15] <mjg59> Ok
[07:15] <fabbione> it will need a proper changelog entry
[07:15] <fabbione> test build
[07:15] <fabbione> and overall configs update
[07:16] <fabbione> on all arches..
[07:16] <mjg59> The ACPI stuff is all from upstream, and I haven't /seen/ any complaints on other architectures
[07:16] <fabbione> mjg59: well.. i would like to see it at least builded everywhere
[07:16] <mjg59> Sure
[07:17] <fabbione> BenC: you might have to ask elmo to upgrade some of the chroots.. iirc i did bump a B-D recently
[07:25] <BenC> so you have to build it on all architectures first, then update the debian/abi/* and then do the source upload?
[07:25] <BenC> oops
[07:35] <fabbione> * committed kernel-team@ubuntu.com--2005/kernel-debian--preX,11--2.6.12--patch-18
[07:35] <fabbione> ok this is the commit with all the ACPI crack
[07:37] <fabbione> https://bugzilla.ubuntu.com/show_bug.cgi?id=11813
[07:37] <fabbione> we forgot the patch in here
[07:37] <mjg59> Oops
[07:37] <mjg59> Sorry, meant to send that to you
[07:37] <fabbione> mjg59: is that patch still needed?
[07:38] <mjg59> Yeah
[07:38] <fabbione> oh my mother just bored me enough on the phone to push me to look at bugzilla for fun
[07:38] <mjg59> Haha
[07:38] <fabbione> i need to go and start to cook dinner
[07:38] <fabbione> BenC: do you want to take care of it?
[07:38] <fabbione> just add it at the end of the list
[07:39] <fabbione> we also need that PATA patch.. and i think we are done for 7.11
[07:39] <fabbione> there is enough crack for the rest of week
[07:40] <fabbione> EHHHH??!?!?!?!???
[07:40] <fabbione> ld  -o tests/nfs_no_rpc crt0.o tests/nfs_no_rpc.o libc.a /usr/lib/gcc/sparc-linux-gnu/4.0.2/libgcc.a
[07:40] <fabbione>  /usr/lib/gcc/sparc-linux-gnu/4.0.2/libgcc.a(_muldi3.o): In function `__muldi3':
[07:40] <fabbione>  : undefined reference to `.umul'
[07:40] <fabbione> I DID FUCKING TEST BUILDED IT BEFORE UPLOAD ON EXACTLY THE SAME CHROOT
[07:41] <fabbione> ah no..
[07:41] <fabbione> different binutils..
[07:41] <fabbione> Grrrrr
[07:42] <BenC> sure
[07:43] <fabbione> BenC: cool
[07:44] <fabbione> BenC: if you feel lucky today, there is libaio that is not ported to sparc ;)
[07:44] <fabbione> it's missing an include file with some asm to generate direct syscalls to the kernel bypassing libc
[07:44] <fabbione> ;)
[07:46] <jbailey> fabbione: Why?
[07:47] <fabbione> async i/O
[07:47] <fabbione> it's faster for certain apps like DB
[07:47] <fabbione> (that's the answer i got from upstream at least)
[07:48] <fabbione> anyway... i need to go now
[07:48] <fabbione> i might pass by later
[07:51] <BenC> later
[07:51] <BenC> I'll check into libaio after I do a kernel build
[07:51] <BenC> or better, while the kernel is building
[07:51] <fabbione> BenC: that one is off line and just for fun :)
[07:51] <fabbione> it's not important for sparc anyway
[07:52] <BenC> ok
[09:22] <michele> hello
[09:22] <michele> I'd like to know if this patch (or something to that effect) is going to make into breezy: http://marc.theaimsgroup.com/?l=linux-kernel&m=111504542402455&w=2
[09:23] <fabbione> no
[09:23] <fabbione> that patch is broken
[09:23] <fabbione> and breaks SCSI
[09:23] <fabbione> + other stuff
[09:23] <michele>  oh nice...
[09:24] <michele> does something else exists to have power mgmt in SATA systems?
[09:24] <fabbione> not yet
[09:24] <michele> so I guess that patch isn't even recommended to apply by myself right?
[09:25] <fabbione> 9/10K
[09:25] <michele> uh?
[09:25] <fabbione> nope
[09:26] <fabbione> don't apply it
[09:26] <michele> ok... sigh
[09:38] <mjg59> fabbione: I still don't see any way it can break SCSI
[09:38] <mjg59> The only way it touches the SCSI layer is to add hooks for suspend/resume
[09:38] <mjg59> On the other hand, it doesn't /work/ for SCSI
[09:39] <fabbione> mjg59: ask greg or jeff.. i really don't know and i don't want to experiment it at 2 weeks from preview
[09:39] <mjg59> fabbione: I spoke to alan about it last week
[09:40] <fabbione> alan C?
[09:40] <mjg59> greg and jeff haven't replied to my mails about it
[09:40] <mjg59> Yeah
[09:40] <fabbione> what did he say?
[09:40] <mjg59> He said he couldn't see any problems with it
[09:42] <mjg59> The only code that touches the SCSI subsystem is scsi_bus_suspend and resume
[09:42] <mjg59> As far as I can tell, the objection is that it doesn't successfully suspend/resume SCSI (but then, that doesn't work /anyway/)
[09:43] <mjg59> The rest of it's all safely contained in the sata layer
[09:43] <fabbione> i think the issue was not SCSI as drivers, but as transport layer
[09:44] <mjg59> It doesn't touch that part of the kernel
[09:44] <mjg59> It's all libata stuff except for scsi_bus_suspend and scsi_bus_resume
[09:44] <fabbione> i know.. but that's what they were talking about
[09:44] <michele> fabbione, I can offer to test it in my thinkpad in case you decide to build a package. I have a spare 5GB.
[09:44] <mjg59> There's absolutely no way that that code can touch it
[09:45] <fabbione> michele: one test is not enough over 2309208 millions different combination of hw
[09:45] <michele> fabbione, I know... just in case you needed it. Not trying to push you.
[09:46] <mjg59> The only thing it will do on a SCSI setup is check whether the driver has a suspend method, and if so call it
[09:46] <fabbione> let me ask again...
[09:46] <fabbione> lamont: build or try to from baz..
[09:46] <mjg59> fabbione: I'm prepared to believe that it's a patch that won't always work, but I can't see any way that it can make things worse than they currently are
[09:47] <mjg59> lamont: Newer acpi crack is in, I have no ia64
[09:47] <fabbione> i committed all the acpi crack 2/3 hours ago
[09:48] <lamont> mjg59: coolness
[09:48] <mjg59> lamont: If you want to send me an ia64 laptop...
[09:49] <lamont> mjg59: I don't think they exist, but a zx2000 might be able to land on your doorstep
[09:50] <lamont> it's kinda like a laptop :-)
[09:50] <lamont> in that it'll fill your lap.
[09:50] <mjg59> lamont: Hmm. Unconvinced.
[09:50] <mjg59> Oh, it's on of /those/
[09:51] <mjg59> Did Microsoft ever ship Windows for Itanium?
[09:52] <fabbione> lamont: i am still waiting for my ia64 and hppa :)
[09:52] <lamont> mjg59: HP certainly shipped it.  I expect that MS is at least supporting it in some manner....
[09:53] <fabbione> mjg59: Jeff says 2 things about that patch that he wrote
[09:53] <fabbione> a) it's experimental and not ready for upstream
[09:53] <fabbione> b) it needs a lot of SCSI love to work properly
[09:53] <mjg59> fabbione: Right. But it /does/ work on some systems.
[09:54] <fabbione> yes.. but it might as well breaks other
[09:54] <fabbione> or make them worst than they are
[09:54] <mjg59> fabbione: Uh. At the moment, suspend/resume is broken on *all* SATA machines.
[09:54] <mjg59> There's no way to make them worse.
[09:54] <fabbione> dude.. that's what he said right now
[09:55] <mjg59> I entirely understand why it's not ready for upstream. He wants it to work properly.
[09:55] <mjg59> But failing to work in some cases is still better than failing to work in all cases.
[09:56] <lamont> mjg59: there's an HP org that supports ia64/windoze
[09:56] <mjg59> lamont: Wow
[09:56] <lamont> not sure how much of that is just front-ending M$, though
[09:57] <fabbione> actually....
[09:57] <fabbione> mjg59: the patch can be splitted in 2 i think
[09:57] <fabbione> mjg59: scsi and sata
[09:57] <mjg59> fabbione: Mm?
[09:57] <fabbione> they look sort of indipendet one from each other..
[09:57] <mjg59> fabbione: No - the SCSI part is needed to call the SATA suspend/resume methods
[09:58] <fabbione> it doesn't look like...
[09:58] <mjg59> Check the scsi_bus_suspend routine. It stops the SCSI queue, checks whether the driver has a suspend method and then calls it
[09:58] <mjg59> +	if (sht->suspend)
[09:58] <mjg59> +		err = sht->suspend(sdev);
[09:59] <fabbione> ah ok..
[09:59] <mjg59> On SATA devices, that'll call ata_scsi_device_suspend
[09:59] <mjg59> On SCSI devices, it's a noop
[09:59] <mjg59> Until someone writes the support for them
[10:00] <mjg59> So the only thing it does on SCSI systems is to call scsi_device_quiesce(sdev) and scsi_device_resume(sdev);
[10:00] <mjg59> Which is safe
[10:01] <fabbione> BenC: what do you think?
[10:23] <fabbione> i am going to sleep on it..
[10:24] <fabbione> BenC: if you think the patch is reasonable.. go ahead and commit it..
[10:25] <fabbione> leave a note in an email on what you will manage to finish, so i don't need to spend time tomorrow digging around...
[10:25] <fabbione> good night ladies
[10:25] <mjg59> Night
[10:28] <fs> mjg59: are the acpi patches for the ubuntu kernel somewhere public?
[10:28] <mjg59> fs: They're in the baz archive
[10:29] <fs> is it more than acpi-20050729-2.6.12.patch.bz2?
[10:29] <fs> or git-latest acpi stuff in -mm?
[10:30] <mjg59> It's acpi-20050729 plus most of the to-linus from git
[10:30] <mjg59> So it ought to be pretty close to 2.6.13 mainline
[10:30] <fs> I see
[10:32] <fs> the acpi patch made battery and thermal working on my turion64 box, a 2.6.13-rc git snapshot from a couple of days ago did not
[10:32] <mjg59> You might want to try the ec_burst_mode parameter
[10:33] <mjg59> Or something like that
[10:34] <fs> where? 
[10:36] <mjg59> On the kernel command line
[10:36] <mjg59> Hang on a sec
[10:37] <mjg59> Depending on your kernel version, there'll either be an ec_polling parameter or an ec_burst= parameter
[10:38] <mjg59> ec_polling will force a kernel that uses burst mode to use polling mode. ec_burst=1 will force a kernel that uses polling mode to use burst mode
[10:39] <fs> I have 2.6.12.5+acpi now, and that looks like it has ec_polling
[11:22] <BenC> anyone been able to verify if the acpi patch fixes any of the reported bugs?
[11:27] <mjg59> BenC: It ought to fix the various delayed ACPI event bugs, the ones where resuming causes "scheduling while atomic" errors and the fact that the screen doesn't lock when the lid is closed
[11:28] <mjg59> But I wasn't bitten by any of those, so it's a bit hard to tell for certain...
[11:29] <BenC> build fails on ppc
[11:30] <BenC> kernel/power/main.c: In function `suspend_finish':
[11:30] <BenC> kernel/power/main.c:126: error: structure has no member named `leave'
[11:30] <BenC> kernel/power/main.c:127: error: structure has no member named `leave'
[11:31] <BenC> debian/patches/drivers-acpi-sleep-main_make-system-ready-to-resume.dpatch is the culprit that adds those lines
[11:32] <mjg59> BenC: Argh. A patch hunk has gone missing, somehow.
[11:33] <BenC> yeah, it's in the patch
[11:33] <BenC> but include/linux/pm.h doesn't seem to contain the patch for the leave member
[11:34] <BenC> wtf
[11:35] <mjg59> BenC: Ok, got a fixed one for you
[11:36] <mjg59> I'll mail it now
[11:37] <mjg59> BenC: Ok, mailed
[11:37] <BenC> duhthe patch isn't getting applied
[11:38] <mjg59> BenC: Uhm. If the patch isn't getting applied, how does it cause the build to fail?
[11:38] <BenC> let me check something
[11:39] <mjg59> But yeah, there was certainly a hunk missing from that patch
[11:39] <BenC> ok
[11:39] <BenC> the patch I was looking at wasn't getting applied
[11:39] <BenC> must be an old one
[11:40] <BenC> the patch that is getting applied didn't have the pm.h hunk
[11:42] <BenC> thanks, got the updated one
[11:44] <BenC> starting the build over
[11:44] <mjg59> BenC: Cool. Sorry about that.
[11:45] <BenC> no problem
[12:05] <BenC> mjg59: drivers-acpi-sleep-main_make-system-ready-to-resume.dpatch was not listed in 00list-7.11, is there any order that it should be in regards to the other acpi patches?
[12:06] <mjg59> BenC: After the global patch. Other than that, I don't think it matters.
[12:08] <BenC> hmm
[12:08] <BenC> I don't think fab added all the patches in 00list-7.11
[12:10] <BenC> I'll get it squared away