On Sun, Jun 02, 2013 at 12:20:56AM +0300, Alexey Suslikov wrote:
> On Sun, Jun 2, 2013 at 12:14 AM, Mark Kettenis <mark.kette...@xs4all.nl> 
> wrote:
> >> Date: Sun, 2 Jun 2013 00:09:25 +0300
> >> From: Alexey Suslikov <alexey.susli...@gmail.com>
> >>
> >> On Sun, Jun 2, 2013 at 12:05 AM, Theo de Raadt <dera...@cvs.openbsd.org> 
> >> wrote:
> >> >> Mike Larkin <mlarkin <at> azathoth.net> writes:
> >> >>
> >> >> > It's sometimes nice to know what devices can wake up a machine, and 
> >> >> > from what
> >> >> > sleep state. But I'm fine suppressing these also. Don't want this to 
> >> >> > end up
> >> >> > being a bikeshed :)
> >> >>
> >> >> why not dnprintf them?
> >> >
> >> > good grief.  We are displaying the information because we still want to 
> >> > see
> >> > it in dmesglogs so that we can improve suspend/resume ...
> >>
> >> is there any possibility to end up with that information being under [...]?
> >
> > acpidump and disassemble the aml
> >
> > anyway, if somebody actually starts working on proper acpi wakeup
> > support, we can temporarily enable printing them all again.
> 
> just an idea (I know more knobs are not good), but sysctl already have some
> acpi related information (indirectly, tho), like
> 
> $ sysctl -a| grep -i acpi
> kern.malloc.kmemnames=free,,devbuf,debug,pcb,routetbl,,fragtbl,,ifaddr,soopts,sysctl,,,ioctlops,,,,,iov,mount,,NFS_req,NFS_mount,,vnodes,namecache,UFS_quota,UFS_mount,shm,VM_map,sem,dirhash,ACPI,VM_pmap,,,,file,file_desc,,proc,subproc,VFS_cluster,,,MFS_node,,,Export_Host,NFS_srvsock,,NFS_daemon,ip_moptions,in_multi,ether_multi,mrt,ISOFS_mount,ISOFS_node,MSDOSFS_mount,MSDOSFS_fat,MSDOSFS_node,ttys,exec,miscfs_mount,,,,,,,,,,pfkey_data,tdb,xform_data,,pagedep,inodedep,newblk,,,indirdep,,,,,,,,,VM_swap,,,,,,UVM_amap,UVM_aobj,,USB,USB_device,USB_HC,,memdesc,,,crypto_data,,IPsec_creds,,,,emuldata,,,,,,,,,ip6_options,NDP,,,temp,NTFS_mount,NTFS_node,NTFS_fnode,NTFS_dir,NTFS_hash,NTFS_attr,NTFS_data,NTFS_decomp,NTFS_vrun,kqueue,bluetooth,bwmeter,UDF_mount,UDF_file_entry,UDF_file_id,Bluetooth_HID,AGP_Memory,DRM
> kern.malloc.kmemstat.ACPI=(inuse = 5429, calls = 20622, memuse = 638K,
> limblocks = 0, mapblocks = 0, maxused = 660K, limit = 78644K, spare =
> 0, sizes = (16,32,64,128,256,512,2048))
> kern.timecounter.hardware=acpihpet0
> kern.timecounter.choice=i8254(0) acpihpet0(1000) acpitimer0(1000)
> dummy(-1000000)
> 
> so maybe wakeup devices may end up under some sysctl path.
> 

This sort of reply is why I don't usually post diffs to tech@.


Reply via email to