At the very end of my startup scripts, I say
pktsetup cdrw /dev/cdrw
to get the stuff in /etc/pktcdvd set up right.
As of 2.6.27 this has started complaining:
pktcdvd: writer pktcdvd0 mapped to hde
------------[ cut here ]------------
WARNING: at fs/sysfs/dir.c:463 sysfs_add_one+0x2f/0x3b()
sysfs: duplicate filename '254:0' can not be created
Modules linked in:
Pid: 1306, comm: pktsetup Not tainted 2.6.27-dirty #1
[<c011ac1c>] warn_slowpath+0x50/0x71
[<c0245c17>] ? ida_get_new_above+0xdc/0x17d
[<c0245a8a>] ? idr_get_empty_slot+0x142/0x1f3
[<c0245c17>] ? ida_get_new_above+0xdc/0x17d
[<c01a1738>] ? sysfs_ilookup_test+0x0/0x16
[<c01a1919>] ? sysfs_find_dirent+0x1b/0x2c
[<c01a1aba>] sysfs_add_one+0x2f/0x3b
[<c01a26f6>] sysfs_do_create_link+0xb1/0x106
[<c01a276b>] sysfs_create_link+0xf/0x14
[<c02749d2>] device_add+0x134/0x455
[<c0274d0a>] device_register+0x17/0x1a
[<c0274d8d>] device_create_vargs+0x80/0xa3
[<c0274dd0>] device_create+0x20/0x24
[<c028208f>] pkt_setup_dev+0x2ed/0x429
[<c0282251>] pkt_ctl_ioctl+0x86/0x18c
[<c0170c09>] vfs_ioctl+0x55/0x6e
[<c0185801>] ? block_truncate_page+0xa9/0x1e0
[<c0170e58>] do_vfs_ioctl+0x236/0x249
[<c0170e9c>] sys_ioctl+0x31/0x4d
[<c0102c8d>] sysenter_do_call+0x12/0x25
[<c0185801>] ? block_truncate_page+0xa9/0x1e0
=======================
---[ end trace 1cdd10ab78ee5bc6 ]---
For the life of me I can't see where pkt_sysfs_dev_new() is being called
more than once: indeed, from the trace above GCC has inlined it into
pkt_setup_dev() as a static function called from only one place...
On Sun, Oct 12, 2008 at 01:26:25PM +0100, Nix wrote:
> At the very end of my startup scripts, I say
>
> pktsetup cdrw /dev/cdrw
>
> to get the stuff in /etc/pktcdvd set up right.
>
> As of 2.6.27 this has started complaining:
>
> pktcdvd: writer pktcdvd0 mapped to hde
> ------------[ cut here ]------------
> WARNING: at fs/sysfs/dir.c:463 sysfs_add_one+0x2f/0x3b()
> sysfs: duplicate filename '254:0' can not be created
> Modules linked in:
> Pid: 1306, comm: pktsetup Not tainted 2.6.27-dirty #1
> [<c011ac1c>] warn_slowpath+0x50/0x71
> [<c0245c17>] ? ida_get_new_above+0xdc/0x17d
> [<c0245a8a>] ? idr_get_empty_slot+0x142/0x1f3
> [<c0245c17>] ? ida_get_new_above+0xdc/0x17d
> [<c01a1738>] ? sysfs_ilookup_test+0x0/0x16
> [<c01a1919>] ? sysfs_find_dirent+0x1b/0x2c
> [<c01a1aba>] sysfs_add_one+0x2f/0x3b
> [<c01a26f6>] sysfs_do_create_link+0xb1/0x106
> [<c01a276b>] sysfs_create_link+0xf/0x14
> [<c02749d2>] device_add+0x134/0x455
> [<c0274d0a>] device_register+0x17/0x1a
> [<c0274d8d>] device_create_vargs+0x80/0xa3
> [<c0274dd0>] device_create+0x20/0x24
> [<c028208f>] pkt_setup_dev+0x2ed/0x429
> [<c0282251>] pkt_ctl_ioctl+0x86/0x18c
> [<c0170c09>] vfs_ioctl+0x55/0x6e
> [<c0185801>] ? block_truncate_page+0xa9/0x1e0
> [<c0170e58>] do_vfs_ioctl+0x236/0x249
> [<c0170e9c>] sys_ioctl+0x31/0x4d
> [<c0102c8d>] sysenter_do_call+0x12/0x25
> [<c0185801>] ? block_truncate_page+0xa9/0x1e0
> =======================
> ---[ end trace 1cdd10ab78ee5bc6 ]---
>
> For the life of me I can't see where pkt_sysfs_dev_new() is being called
> more than once: indeed, from the trace above GCC has inlined it into
> pkt_setup_dev() as a static function called from only one place...
Perhaps some other kernel code is registering with that same major/minor
number, making it already present in sysfs. Where does that sysfs file
link to before you load your driver?
thanks,
greg k-h
On 12 Oct 2008, Greg KH stated:
> Perhaps some other kernel code is registering with that same major/minor
> number, making it already present in sysfs. Where does that sysfs file
> link to before you load your driver?
It's not modular right now so it's sort of hard to tell. I'll rebuild it
as a module and have a look (be a while before I can reboot though,
other people are using this machine right now).
Turned-on items in .config, FWIW:
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_FAST_CMPXCHG_LOCAL=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_ARCH_SUPPORTS_AOUT=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_KTIME_SCALAR=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_LOG_BUF_SHIFT=14
CONFIG_CGROUPS=y
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_GROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_RT_GROUP_SCHED=y
CONFIG_USER_SCHED=y
CONFIG_RELAY=y
CONFIG_NAMESPACES=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE="usr/initramfs.hades"
CONFIG_INITRAMFS_ROOT_UID=99
CONFIG_INITRAMFS_ROOT_GID=101
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_PCSPKR_PLATFORM=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLAB=y
CONFIG_PROFILING=y
CONFIG_MARKERS=y
CONFIG_OPROFILE=y
CONFIG_HAVE_OPROFILE=y
CONFIG_KPROBES=y
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_KRETPROBES=y
CONFIG_HAVE_IOREMAP_PROT=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_KMOD=y
CONFIG_BLOCK=y
CONFIG_BLK_DEV_IO_TRACE=y
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=m
CONFIG_IOSCHED_DEADLINE=m
CONFIG_IOSCHED_CFQ=y
CONFIG_DEFAULT_CFQ=y
CONFIG_DEFAULT_IOSCHED="cfq"
CONFIG_CLASSIC_RCU=y
CONFIG_TICK_ONESHOT=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y
CONFIG_X86_PC=y
CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
CONFIG_MK7=y
CONFIG_X86_CPU=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_XADD=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_USE_3DNOW=y
CONFIG_X86_TSC=y
CONFIG_X86_CMOV=y
CONFIG_X86_MINIMUM_CPU_FAMILY=4
CONFIG_X86_DEBUGCTLMSR=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_DMI=y
CONFIG_PREEMPT=y
CONFIG_X86_UP_APIC=y
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_NONFATAL=y
CONFIG_VM86=y
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m
CONFIG_NOHIGHMEM=y
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_SPARSEMEM_STATIC=y
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
CONFIG_MTRR=y
CONFIG_X86_PAT=y
CONFIG_SECCOMP=y
CONFIG_HZ_1000=y
CONFIG_HZ=1000
CONFIG_SCHED_HRTICK=y
CONFIG_PHYSICAL_START=0x100000
CONFIG_PHYSICAL_ALIGN=0x100000
CONFIG_PM=y
CONFIG_PCI=y
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_DOMAINS=y
CONFIG_ARCH_SUPPORTS_MSI=y
CONFIG_ISA_DMA_API=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_FIB_HASH=y
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
CONFIG_EXTRA_FIRMWARE=""
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
CONFIG_PARPORT_1284=y
CONFIG_BLK_DEV=y
CONFIG_BLK_DEV_FD=y
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_CRYPTOLOOP=m
CONFIG_BLK_DEV_NBD=m
CONFIG_CDROM_PKTCDVD=y
CONFIG_CDROM_PKTCDVD_BUFFERS=16
CONFIG_MISC_DEVICES=y
CONFIG_HAVE_IDE=y
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
CONFIG_IDE_TIMINGS=y
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDECD=y
CONFIG_BLK_DEV_IDECD_VERBOSE_ERRORS=y
CONFIG_IDE_GENERIC=y
CONFIG_BLK_DEV_IDEDMA_SFF=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_PCIBUS_ORDER=y
CONFIG_BLK_DEV_OFFBOARD=y
CONFIG_BLK_DEV_GENERIC=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_BLK_DEV_PDC202XX_NEW=y
CONFIG_BLK_DEV_VIA82CXXX=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_SCSI=m
CONFIG_SCSI_DMA=y
CONFIG_BLK_DEV_SD=m
CONFIG_SCSI_SCAN_ASYNC=y
CONFIG_SCSI_WAIT_SCAN=m
CONFIG_SCSI_LOWLEVEL=y
CONFIG_MD=y
CONFIG_BLK_DEV_DM=y
CONFIG_DM_CRYPT=y
CONFIG_DM_SNAPSHOT=y
CONFIG_DM_MIRROR=y
CONFIG_DM_ZERO=y
CONFIG_NETDEVICES=y
CONFIG_DUMMY=m
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
CONFIG_NET_VENDOR_3COM=y
CONFIG_VORTEX=y
CONFIG_INPUT=y
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
CONFIG_INPUT_JOYDEV=y
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_MOUSE_PS2_ALPS=y
CONFIG_MOUSE_PS2_LOGIPS2PP=y
CONFIG_MOUSE_PS2_SYNAPTICS=y
CONFIG_MOUSE_PS2_LIFEBOOK=y
CONFIG_MOUSE_PS2_TRACKPOINT=y
CONFIG_INPUT_JOYSTICK=y
CONFIG_JOYSTICK_ANALOG=y
CONFIG_INPUT_MISC=y
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_LIBPS2=y
CONFIG_GAMEPORT=y
CONFIG_GAMEPORT_EMU10K1=y
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_SERIAL_8250=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_CORE=y
CONFIG_UNIX98_PTYS=y
CONFIG_PRINTER=m
CONFIG_DEVPORT=y
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_CHARDEV=y
CONFIG_I2C_HELPER_AUTO=y
CONFIG_I2C_VIAPRO=y
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
CONFIG_HWMON=y
CONFIG_HWMON_VID=y
CONFIG_SENSORS_W83627HF=y
CONFIG_THERMAL_HWMON=y
CONFIG_SSB_POSSIBLE=y
CONFIG_AGP=y
CONFIG_AGP_VIA=y
CONFIG_DRM=m
CONFIG_DRM_RADEON=m
CONFIG_VGA_CONSOLE=y
CONFIG_VIDEO_SELECT=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_SOUND=y
CONFIG_SND=y
CONFIG_SND_TIMER=y
CONFIG_SND_PCM=y
CONFIG_SND_HWDEP=y
CONFIG_SND_RAWMIDI=y
CONFIG_SND_SEQUENCER=y
CONFIG_SND_SEQ_DUMMY=m
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=y
CONFIG_SND_PCM_OSS=y
CONFIG_SND_PCM_OSS_PLUGINS=y
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_VERBOSE_PROCFS=y
CONFIG_SND_VMASTER=y
CONFIG_SND_MPU401_UART=m
CONFIG_SND_AC97_CODEC=y
CONFIG_SND_DRIVERS=y
CONFIG_SND_MPU401=m
CONFIG_SND_PCI=y
CONFIG_SND_EMU10K1=y
CONFIG_AC97_BUS=y
CONFIG_USB_SUPPORT=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB=y
CONFIG_USB_DEVICEFS=y
CONFIG_USB_DYNAMIC_MINORS=y
CONFIG_USB_UHCI_HCD=y
CONFIG_USB_PRINTER=y
CONFIG_USB_STORAGE=m
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
CONFIG_RTC_DRV_CMOS=y
CONFIG_AUXDISPLAY=y
CONFIG_FIRMWARE_MEMMAP=y
CONFIG_DMIID=y
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_JBD=y
CONFIG_FS_MBCACHE=y
CONFIG_REISERFS_FS=y
CONFIG_REISERFS_FS_XATTR=y
CONFIG_REISERFS_FS_POSIX_ACL=y
CONFIG_FS_POSIX_ACL=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
CONFIG_QUOTA=y
CONFIG_QUOTA_NETLINK_INTERFACE=y
CONFIG_PRINT_QUOTA_WARNING=y
CONFIG_QFMT_V2=y
CONFIG_QUOTACTL=y
CONFIG_FUSE_FS=y
CONFIG_GENERIC_ACL=y
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_UDF_FS=y
CONFIG_UDF_NLS=y
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=m
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
CONFIG_PROC_FS=y
CONFIG_PROC_SYSCTL=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
CONFIG_CONFIGFS_FS=y
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFSD=y
CONFIG_NFSD_V2_ACL=y
CONFIG_NFSD_V3=y
CONFIG_NFSD_V3_ACL=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=y
CONFIG_NFS_ACL_SUPPORT=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
CONFIG_PARTITION_ADVANCED=y
CONFIG_MSDOS_PARTITION=y
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=y
CONFIG_NLS_ASCII=m
CONFIG_NLS_ISO8859_1=y
CONFIG_NLS_ISO8859_15=m
CONFIG_NLS_UTF8=m
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=1024
CONFIG_DEBUG_FS=y
CONFIG_DEBUG_KERNEL=y
CONFIG_DETECT_SOFTLOCKUP=y
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0
CONFIG_SCHED_DEBUG=y
CONFIG_SCHEDSTATS=y
CONFIG_TIMER_STATS=y
CONFIG_STACKTRACE=y
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_MEMORY_INIT=y
CONFIG_FRAME_POINTER=y
CONFIG_LATENCYTOP=y
CONFIG_SYSCTL_SYSCALL_CHECK=y
CONFIG_HAVE_FTRACE=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_TRACER_MAX_TRACE=y
CONFIG_TRACING=y
CONFIG_FTRACE=y
CONFIG_SYSPROF_TRACER=y
CONFIG_SCHED_TRACER=y
CONFIG_CONTEXT_SWITCH_TRACER=y
CONFIG_DYNAMIC_FTRACE=y
CONFIG_HAVE_ARCH_KGDB=y
CONFIG_STRICT_DEVMEM=y
CONFIG_X86_VERBOSE_BOOTUP=y
CONFIG_EARLY_PRINTK=y
CONFIG_DEBUG_RODATA=y
CONFIG_DOUBLEFAULT=y
CONFIG_IO_DELAY_TYPE_0X80=0
CONFIG_IO_DELAY_TYPE_0XED=1
CONFIG_IO_DELAY_TYPE_UDELAY=2
CONFIG_IO_DELAY_TYPE_NONE=3
CONFIG_IO_DELAY_0X80=y
CONFIG_DEFAULT_IO_DELAY_TYPE=0
CONFIG_SECURITY_FILE_CAPABILITIES=y
CONFIG_CRYPTO=y
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_CBC=y
CONFIG_HAVE_KVM=y
CONFIG_BITREVERSE=y
CONFIG_GENERIC_FIND_FIRST_BIT=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
CONFIG_CRC_ITU_T=y
CONFIG_CRC32=y
CONFIG_ZLIB_INFLATE=y
CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
--
`Not even vi uses vi key bindings for its command line.' --- PdS
On Sun, Oct 12, 2008 at 09:25:07PM +0100, Nix wrote:
> On 12 Oct 2008, Greg KH stated:
> > Perhaps some other kernel code is registering with that same major/minor
> > number, making it already present in sysfs. Where does that sysfs file
> > link to before you load your driver?
>
> It's not modular right now so it's sort of hard to tell. I'll rebuild it
> as a module and have a look (be a while before I can reboot though,
> other people are using this machine right now).
How about before you run that command on the machine?
thanks,
greg k-h
On 12 Oct 2008, Greg KH verbalised:
> On Sun, Oct 12, 2008 at 09:25:07PM +0100, Nix wrote:
>> On 12 Oct 2008, Greg KH stated:
>> > Perhaps some other kernel code is registering with that same major/minor
>> > number, making it already present in sysfs. Where does that sysfs file
>> > link to before you load your driver?
>>
>> It's not modular right now so it's sort of hard to tell. I'll rebuild it
>> as a module and have a look (be a while before I can reboot though,
>> other people are using this machine right now).
>
> How about before you run that command on the machine?
Oh, er, true, that would work too.
Still needs a reboot though :/
--
`Not even vi uses vi key bindings for its command line.' --- PdS
Greg KH <[email protected]> writes:
> On Sun, Oct 12, 2008 at 01:26:25PM +0100, Nix wrote:
>> At the very end of my startup scripts, I say
>>
>> pktsetup cdrw /dev/cdrw
>>
>> to get the stuff in /etc/pktcdvd set up right.
>>
>> As of 2.6.27 this has started complaining:
>>
>> pktcdvd: writer pktcdvd0 mapped to hde
>> ------------[ cut here ]------------
>> WARNING: at fs/sysfs/dir.c:463 sysfs_add_one+0x2f/0x3b()
>> sysfs: duplicate filename '254:0' can not be created
>> Modules linked in:
>> Pid: 1306, comm: pktsetup Not tainted 2.6.27-dirty #1
>> [<c011ac1c>] warn_slowpath+0x50/0x71
>> [<c0245c17>] ? ida_get_new_above+0xdc/0x17d
>> [<c0245a8a>] ? idr_get_empty_slot+0x142/0x1f3
>> [<c0245c17>] ? ida_get_new_above+0xdc/0x17d
>> [<c01a1738>] ? sysfs_ilookup_test+0x0/0x16
>> [<c01a1919>] ? sysfs_find_dirent+0x1b/0x2c
>> [<c01a1aba>] sysfs_add_one+0x2f/0x3b
>> [<c01a26f6>] sysfs_do_create_link+0xb1/0x106
>> [<c01a276b>] sysfs_create_link+0xf/0x14
>> [<c02749d2>] device_add+0x134/0x455
>> [<c0274d0a>] device_register+0x17/0x1a
>> [<c0274d8d>] device_create_vargs+0x80/0xa3
>> [<c0274dd0>] device_create+0x20/0x24
>> [<c028208f>] pkt_setup_dev+0x2ed/0x429
>> [<c0282251>] pkt_ctl_ioctl+0x86/0x18c
>> [<c0170c09>] vfs_ioctl+0x55/0x6e
>> [<c0185801>] ? block_truncate_page+0xa9/0x1e0
>> [<c0170e58>] do_vfs_ioctl+0x236/0x249
>> [<c0170e9c>] sys_ioctl+0x31/0x4d
>> [<c0102c8d>] sysenter_do_call+0x12/0x25
>> [<c0185801>] ? block_truncate_page+0xa9/0x1e0
>> =======================
>> ---[ end trace 1cdd10ab78ee5bc6 ]---
>>
>> For the life of me I can't see where pkt_sysfs_dev_new() is being called
>> more than once: indeed, from the trace above GCC has inlined it into
>> pkt_setup_dev() as a static function called from only one place...
>
> Perhaps some other kernel code is registering with that same major/minor
> number, making it already present in sysfs. Where does that sysfs file
> link to before you load your driver?
I've just got a similar message from 2.6.27 but involving vcs1. I
didn't get this with 2.6.26.6 and I've booted 2.6.27 a few times and
only seen it once:
WARNING: at fs/sysfs/dir.c:463 sysfs_add_one+0x33/0x3a()
sysfs: duplicate filename 'vcs1' can not be created
Modules linked in: xt_tcpudp nfs nfsd lockd nfs_acl auth_rpcgss sunrpc exportfs
ppdev lp ac battery xt_state ipt_MASQUERADE ipv6 ipt_LOG iptable_mangle iptable_
filter iptable_nat ip_tables nf_nat x_tables nf_conntrack_ipv4 nf_conntrack tun
dm_crypt crypto_blkcipher coretemp it87 hwmon_vid loop snd_hda_intel snd_pcm_oss
snd_mixer_oss snd_pcm snd_timer sg iTCO_wdt snd serio_raw i2c_i801 sr_mod i2c_c
ore parport_pc soundcore psmouse intel_agp parport button pcspkr snd_page_alloc
cdrom evdev ext3 jbd mbcache dm_mirror dm_log dm_snapshot dm_mod usbhid hid sd_m
od ata_piix libata r8169 ehci_hcd uhci_hcd thermal processor fan thermal_sys
Pid: 3841, comm: getty Not tainted 2.6.27 #1
Call Trace:
[<ffffffff802347d0>] warn_slowpath+0xb4/0xdc
[<ffffffff802284dc>] source_load+0x2a/0x58
[<ffffffff802f85c9>] __next_cpu+0x19/0x26
[<ffffffff802fd7de>] string+0x34/0x93
[<ffffffff802fdb59>] vsnprintf+0x31c/0x5be
[<ffffffff802f8c33>] idr_get_empty_slot+0x164/0x243
[<ffffffff802f8e08>] ida_get_new_above+0xf6/0x182
[<ffffffff80292ead>] find_inode+0x28/0x6d
[<ffffffff802c4a10>] sysfs_ilookup_test+0x0/0xf
[<ffffffff802c4c45>] sysfs_find_dirent+0x1b/0x2f
[<ffffffff802c4d22>] sysfs_add_one+0x33/0x3a
[<ffffffff802c521e>] create_dir+0x4f/0x7c
[<ffffffff802c5280>] sysfs_create_dir+0x35/0x4a
[<ffffffff802f983e>] kobject_get+0x12/0x17
[<ffffffff802f9977>] kobject_add_internal+0xcf/0x18a
[<ffffffff802f9f53>] kobject_add+0x74/0x7c
[<ffffffffa009e9bc>] journal_stop+0x176/0x182 [jbd]
[<ffffffffa00b1adf>] ext3_ordered_write_end+0xfc/0x112 [ext3]
[<ffffffff802f983e>] kobject_get+0x12/0x17
[<ffffffff80364174>] get_device+0x17/0x1f
[<ffffffff8036479e>] device_add+0x9e/0x5cc
[<ffffffff802f9637>] kobject_init_internal+0x12/0x2c
[<ffffffff802f96af>] kobject_init+0x41/0x69
[<ffffffff80364d76>] device_create_vargs+0x98/0xc4
[<ffffffff80364ddc>] device_create+0x3a/0x42
[<ffffffff802295c6>] __wake_up+0x38/0x4f
[<ffffffff8034d38d>] tty_ldisc_setup+0x63/0x6a
[<ffffffff80347a29>] init_dev+0x390/0x4a9
[<ffffffff8035542b>] vc_allocate+0x10/0x13f
[<ffffffff8034fc55>] vcs_make_sysfs+0x2d/0x5b
[<ffffffff803555ed>] con_open+0x93/0xa0
[<ffffffff803498fb>] tty_open+0x1ae/0x32d
[<ffffffff80284aee>] chrdev_open+0x131/0x15b
[<ffffffff802849bd>] chrdev_open+0x0/0x15b
[<ffffffff80280c06>] __dentry_open+0x13c/0x246
[<ffffffff8028bda7>] do_filp_open+0x38a/0x6d3
[<ffffffff8022947f>] need_resched+0x1e/0x28
[<ffffffff80294a27>] alloc_fd+0xb5/0xf9
[<ffffffff80280a06>] do_sys_open+0x48/0xcc
[<ffffffff8020bfab>] system_call_fastpath+0x16/0x1b
On 12 Oct 2008, Greg KH uttered the following:
> Perhaps some other kernel code is registering with that same major/minor
> number, making it already present in sysfs. Where does that sysfs file
> link to before you load your driver?
Exactly so. This is probably *not* a regression after all: the only
change I made to my 2.6.27 config (weeks before actually rebooting, so I
forgot) was to build in the CMOS RTC driver, in a hopeless attempt to
make hrtimers work on this old hardware (I knew it was hopeless but
tried anyway). (Unsurprisingly it didn't work:
<http://www.ussg.iu.edu/hypermail/linux/kernel/0810.1/1033.html> worked,
thank *you* Jeff, I have glitch-free pulseaudio and microsecond sleeps
and several of my programs are happier!)
And, looky here, a smoking gun:
hades:~# ls -l /sys/dev/char/254:0 /dev/rtc*
lrwxrwxrwx 1 root root 0 2008-10-13 22:16 /sys/dev/char/254:0 -> ../../devices/platform/rtc_cmos/rtc/rtc0
hades:~# ls -l
lrwxrwxrwx 1 root root 4 2008-10-13 21:57 /dev/rtc -> rtc0
crw-r--r-- 1 root root 254, 0 2008-10-13 21:57 /dev/rtc0
hades:~# pktsetup cdrw /dev/cdrw
hades:~# ls -l /dev/pktcdvd/
total 0
brw-r----- 1 root root 254, 0 2008-10-13 22:23 cdrw
crw-r--r-- 1 root root 10, 63 2008-10-13 21:57 control
brw-rw---- 1 root cdrom 254, 0 2008-10-13 22:23 pktcdvd0
Am I right in assuming that this sort of isn't going to work? :)
Major 254 is listed as LOCAL/EXPERIMENTAL USE in devices.txt. I don't
consider either pktcdvd or the rtc drivers as LOCAL/EXPERIMENTAL: the
former in particular has been in the kernel for years.
They could do with proper device numbers. No matter what this is going
to break some non-udev setups :(
On Mon, Oct 13, 2008 at 10:28:13PM +0100, Nix wrote:
> On 12 Oct 2008, Greg KH uttered the following:
> > Perhaps some other kernel code is registering with that same major/minor
> > number, making it already present in sysfs. Where does that sysfs file
> > link to before you load your driver?
>
> Exactly so. This is probably *not* a regression after all: the only
> change I made to my 2.6.27 config (weeks before actually rebooting, so I
> forgot) was to build in the CMOS RTC driver, in a hopeless attempt to
> make hrtimers work on this old hardware (I knew it was hopeless but
> tried anyway). (Unsurprisingly it didn't work:
> <http://www.ussg.iu.edu/hypermail/linux/kernel/0810.1/1033.html> worked,
> thank *you* Jeff, I have glitch-free pulseaudio and microsecond sleeps
> and several of my programs are happier!)
>
> And, looky here, a smoking gun:
>
> hades:~# ls -l /sys/dev/char/254:0 /dev/rtc*
> lrwxrwxrwx 1 root root 0 2008-10-13 22:16 /sys/dev/char/254:0 -> ../../devices/platform/rtc_cmos/rtc/rtc0
> hades:~# ls -l
> lrwxrwxrwx 1 root root 4 2008-10-13 21:57 /dev/rtc -> rtc0
> crw-r--r-- 1 root root 254, 0 2008-10-13 21:57 /dev/rtc0
>
> hades:~# pktsetup cdrw /dev/cdrw
> hades:~# ls -l /dev/pktcdvd/
> total 0
> brw-r----- 1 root root 254, 0 2008-10-13 22:23 cdrw
> crw-r--r-- 1 root root 10, 63 2008-10-13 21:57 control
> brw-rw---- 1 root cdrom 254, 0 2008-10-13 22:23 pktcdvd0
>
> Am I right in assuming that this sort of isn't going to work? :)
Yes, you are right :)
> Major 254 is listed as LOCAL/EXPERIMENTAL USE in devices.txt. I don't
> consider either pktcdvd or the rtc drivers as LOCAL/EXPERIMENTAL: the
> former in particular has been in the kernel for years.
Both of those should get "real" majors assigned to them. It's not ok to
randomly go grabbing major:minor numbers like this for code that is in
mainline.
> They could do with proper device numbers. No matter what this is going
> to break some non-udev setups :(
It's going to break all setups, no matter if udev is involved here or
not...
thanks,
greg k-h
On Mon, 13 Oct 2008 14:47:47 -0700
Greg KH <[email protected]> wrote:
> > Major 254 is listed as LOCAL/EXPERIMENTAL USE in devices.txt. I don't
> > consider either pktcdvd or the rtc drivers as LOCAL/EXPERIMENTAL: the
> > former in particular has been in the kernel for years.
>
> Both of those should get "real" majors assigned to them. It's not ok to
> randomly go grabbing major:minor numbers like this for code that is in
> mainline.
the rtc dev uses dynamically assigned numbers, as does pktcdvd, so they
should be able to coexist . maybe the problem lies in the pktsetup
utility.
--
Best regards,
Alessandro Zummo,
Tower Technologies - Torino, Italy
http://www.towertech.it
On 13 Oct 2008, Greg KH verbalised:
> On Mon, Oct 13, 2008 at 10:28:13PM +0100, Nix wrote:
>> They could do with proper device numbers. No matter what this is going
>> to break some non-udev setups :(
>
> It's going to break all setups, no matter if udev is involved here or
> not...
I meant the *renumbering* would break static /dev. Obviously the
duplication is going to break things :)
--
`Not even vi uses vi key bindings for its command line.' --- PdS
Greg KH <[email protected]> writes:
> On Mon, Oct 13, 2008 at 10:28:13PM +0100, Nix wrote:
>> On 12 Oct 2008, Greg KH uttered the following:
>> > Perhaps some other kernel code is registering with that same major/minor
>> > number, making it already present in sysfs. Where does that sysfs file
>> > link to before you load your driver?
>>
>> Exactly so. This is probably *not* a regression after all: the only
>> change I made to my 2.6.27 config (weeks before actually rebooting, so I
>> forgot) was to build in the CMOS RTC driver, in a hopeless attempt to
>> make hrtimers work on this old hardware (I knew it was hopeless but
>> tried anyway). (Unsurprisingly it didn't work:
>> <http://www.ussg.iu.edu/hypermail/linux/kernel/0810.1/1033.html> worked,
>> thank *you* Jeff, I have glitch-free pulseaudio and microsecond sleeps
>> and several of my programs are happier!)
>>
>> And, looky here, a smoking gun:
>>
>> hades:~# ls -l /sys/dev/char/254:0 /dev/rtc*
>> lrwxrwxrwx 1 root root 0 2008-10-13 22:16 /sys/dev/char/254:0 -> ../../devices/platform/rtc_cmos/rtc/rtc0
>> hades:~# ls -l
>> lrwxrwxrwx 1 root root 4 2008-10-13 21:57 /dev/rtc -> rtc0
>> crw-r--r-- 1 root root 254, 0 2008-10-13 21:57 /dev/rtc0
>>
>> hades:~# pktsetup cdrw /dev/cdrw
>> hades:~# ls -l /dev/pktcdvd/
>> total 0
>> brw-r----- 1 root root 254, 0 2008-10-13 22:23 cdrw
>> crw-r--r-- 1 root root 10, 63 2008-10-13 21:57 control
>> brw-rw---- 1 root cdrom 254, 0 2008-10-13 22:23 pktcdvd0
>>
>> Am I right in assuming that this sort of isn't going to work? :)
>
> Yes, you are right :)
I don't think so. One is a character device and the other is a block
device. Block devices didn't use to collide with character devices.
Has that changed recently?
>> Major 254 is listed as LOCAL/EXPERIMENTAL USE in devices.txt. I don't
>> consider either pktcdvd or the rtc drivers as LOCAL/EXPERIMENTAL: the
>> former in particular has been in the kernel for years.
>
> Both of those should get "real" majors assigned to them. It's not ok to
> randomly go grabbing major:minor numbers like this for code that is in
> mainline.
It's not about random grabbing. It's about getting a dynamically
assigned number. The pktcdvd driver once had static numbers, but at
the time when the driver was merged into the mainline kernel, dynamic
numbers were considered better. Therefore I changed the driver to use
dynamic numbers.
--
Peter Osterlund - [email protected]
http://web.telia.com/~u89404340
On Tue, Oct 14, 2008 at 7:27 AM, Peter Osterlund <[email protected]> wrote:
> Greg KH <[email protected]> writes:
>
>> On Mon, Oct 13, 2008 at 10:28:13PM +0100, Nix wrote:
>>> On 12 Oct 2008, Greg KH uttered the following:
>>> > Perhaps some other kernel code is registering with that same major/minor
>>> > number, making it already present in sysfs. Where does that sysfs file
>>> > link to before you load your driver?
>>>
>>> Exactly so. This is probably *not* a regression after all: the only
>>> change I made to my 2.6.27 config (weeks before actually rebooting, so I
>>> forgot) was to build in the CMOS RTC driver, in a hopeless attempt to
>>> make hrtimers work on this old hardware (I knew it was hopeless but
>>> tried anyway). (Unsurprisingly it didn't work:
>>> <http://www.ussg.iu.edu/hypermail/linux/kernel/0810.1/1033.html> worked,
>>> thank *you* Jeff, I have glitch-free pulseaudio and microsecond sleeps
>>> and several of my programs are happier!)
>>>
>>> And, looky here, a smoking gun:
>>>
>>> hades:~# ls -l /sys/dev/char/254:0 /dev/rtc*
>>> lrwxrwxrwx 1 root root 0 2008-10-13 22:16 /sys/dev/char/254:0 -> ../../devices/platform/rtc_cmos/rtc/rtc0
>>> hades:~# ls -l
>>> lrwxrwxrwx 1 root root 4 2008-10-13 21:57 /dev/rtc -> rtc0
>>> crw-r--r-- 1 root root 254, 0 2008-10-13 21:57 /dev/rtc0
>>>
>>> hades:~# pktsetup cdrw /dev/cdrw
>>> hades:~# ls -l /dev/pktcdvd/
>>> total 0
>>> brw-r----- 1 root root 254, 0 2008-10-13 22:23 cdrw
>>> crw-r--r-- 1 root root 10, 63 2008-10-13 21:57 control
>>> brw-rw---- 1 root cdrom 254, 0 2008-10-13 22:23 pktcdvd0
>>>
>>> Am I right in assuming that this sort of isn't going to work? :)
>>
>> Yes, you are right :)
>
> I don't think so. One is a character device and the other is a block
> device. Block devices didn't use to collide with character devices.
> Has that changed recently?
No, that's still true.
>>> Major 254 is listed as LOCAL/EXPERIMENTAL USE in devices.txt. I don't
>>> consider either pktcdvd or the rtc drivers as LOCAL/EXPERIMENTAL: the
>>> former in particular has been in the kernel for years.
>>
>> Both of those should get "real" majors assigned to them. It's not ok to
>> randomly go grabbing major:minor numbers like this for code that is in
>> mainline.
>
> It's not about random grabbing. It's about getting a dynamically
> assigned number. The pktcdvd driver once had static numbers, but at
> the time when the driver was merged into the mainline kernel, dynamic
> numbers were considered better. Therefore I changed the driver to use
> dynamic numbers.
The pktcdvd driver allocates a dynamic block major, which is fine. But
doesn't it use the same number, and now not allocated, for the char
devices it uses? That looks like something that needs to fixed, right?
static void pkt_sysfs_dev_new(struct pktcdvd_device *pd)
{
if (class_pktcdvd) {
pd->dev = device_create_drvdata(class_pktcdvd, NULL,
pd->pkt_dev, NULL,
"%s", pd->name);
Thanks,
Kay
On Tue, 2008-10-14 at 10:38 +0200, Kay Sievers wrote:
> On Tue, Oct 14, 2008 at 7:27 AM, Peter Osterlund <[email protected]> wrote:
> > Greg KH <[email protected]> writes:
> >
> >> On Mon, Oct 13, 2008 at 10:28:13PM +0100, Nix wrote:
> >>> On 12 Oct 2008, Greg KH uttered the following:
> >>> > Perhaps some other kernel code is registering with that same major/minor
> >>> > number, making it already present in sysfs. Where does that sysfs file
> >>> > link to before you load your driver?
> >>>
> >>> Exactly so. This is probably *not* a regression after all: the only
> >>> change I made to my 2.6.27 config (weeks before actually rebooting, so I
> >>> forgot) was to build in the CMOS RTC driver, in a hopeless attempt to
> >>> make hrtimers work on this old hardware (I knew it was hopeless but
> >>> tried anyway). (Unsurprisingly it didn't work:
> >>> <http://www.ussg.iu.edu/hypermail/linux/kernel/0810.1/1033.html> worked,
> >>> thank *you* Jeff, I have glitch-free pulseaudio and microsecond sleeps
> >>> and several of my programs are happier!)
> >>>
> >>> And, looky here, a smoking gun:
> >>>
> >>> hades:~# ls -l /sys/dev/char/254:0 /dev/rtc*
> >>> lrwxrwxrwx 1 root root 0 2008-10-13 22:16 /sys/dev/char/254:0 -> ../../devices/platform/rtc_cmos/rtc/rtc0
> >>> hades:~# ls -l
> >>> lrwxrwxrwx 1 root root 4 2008-10-13 21:57 /dev/rtc -> rtc0
> >>> crw-r--r-- 1 root root 254, 0 2008-10-13 21:57 /dev/rtc0
> >>>
> >>> hades:~# pktsetup cdrw /dev/cdrw
> >>> hades:~# ls -l /dev/pktcdvd/
> >>> total 0
> >>> brw-r----- 1 root root 254, 0 2008-10-13 22:23 cdrw
> >>> crw-r--r-- 1 root root 10, 63 2008-10-13 21:57 control
> >>> brw-rw---- 1 root cdrom 254, 0 2008-10-13 22:23 pktcdvd0
> >>>
> >>> Am I right in assuming that this sort of isn't going to work? :)
> >>
> >> Yes, you are right :)
> >
> > I don't think so. One is a character device and the other is a block
> > device. Block devices didn't use to collide with character devices.
> > Has that changed recently?
>
> No, that's still true.
>
> >>> Major 254 is listed as LOCAL/EXPERIMENTAL USE in devices.txt. I don't
> >>> consider either pktcdvd or the rtc drivers as LOCAL/EXPERIMENTAL: the
> >>> former in particular has been in the kernel for years.
> >>
> >> Both of those should get "real" majors assigned to them. It's not ok to
> >> randomly go grabbing major:minor numbers like this for code that is in
> >> mainline.
> >
> > It's not about random grabbing. It's about getting a dynamically
> > assigned number. The pktcdvd driver once had static numbers, but at
> > the time when the driver was merged into the mainline kernel, dynamic
> > numbers were considered better. Therefore I changed the driver to use
> > dynamic numbers.
>
> The pktcdvd driver allocates a dynamic block major, which is fine. But
> doesn't it use the same number, and now not allocated, for the char
> devices it uses? That looks like something that needs to fixed, right?
>
> static void pkt_sysfs_dev_new(struct pktcdvd_device *pd)
> {
> if (class_pktcdvd) {
> pd->dev = device_create_drvdata(class_pktcdvd, NULL,
> pd->pkt_dev, NULL,
> "%s", pd->name);
Something similar to this, with error checking, might be needed. It has
two independent majors now in block and char:
$ grep pkt /proc/devices
251 pktcdvd-char
252 pktcdvd
diff --git a/drivers/block/pktcdvd.c b/drivers/block/pktcdvd.c
index 29b7a64..07dd157 100644
--- a/drivers/block/pktcdvd.c
+++ b/drivers/block/pktcdvd.c
@@ -86,6 +86,7 @@
static struct pktcdvd_device *pkt_devs[MAX_WRITERS];
static struct proc_dir_entry *pkt_proc;
static int pktdev_major;
+static int pktdev_char_major;
static int write_congestion_on = PKT_WRITE_CONGESTION_ON;
static int write_congestion_off = PKT_WRITE_CONGESTION_OFF;
static struct mutex ctl_mutex; /* Serialize open/close/setup/teardown */
@@ -301,9 +302,11 @@ static struct kobj_type kobj_pkt_type_wqueue = {
static void pkt_sysfs_dev_new(struct pktcdvd_device *pd)
{
+ dev_t devno = MKDEV(pktdev_char_major, MINOR(pd->pkt_dev));
+
if (class_pktcdvd) {
pd->dev = device_create_drvdata(class_pktcdvd, NULL,
- pd->pkt_dev, NULL,
+ devno, NULL,
"%s", pd->name);
if (IS_ERR(pd->dev))
pd->dev = NULL;
@@ -320,10 +323,12 @@ static void pkt_sysfs_dev_new(struct pktcdvd_device *pd)
static void pkt_sysfs_dev_remove(struct pktcdvd_device *pd)
{
+ dev_t devno = MKDEV(pktdev_char_major, MINOR(pd->pkt_dev));
+
pkt_kobj_remove(pd->kobj_stat);
pkt_kobj_remove(pd->kobj_wqueue);
if (class_pktcdvd)
- device_destroy(class_pktcdvd, pd->pkt_dev);
+ device_destroy(class_pktcdvd, devno);
}
@@ -3067,6 +3072,7 @@ static struct miscdevice pkt_misc = {
static int __init pkt_init(void)
{
int ret;
+ dev_t devno;
mutex_init(&ctl_mutex);
@@ -3083,6 +3089,9 @@ static int __init pkt_init(void)
if (!pktdev_major)
pktdev_major = ret;
+ alloc_chrdev_region(&devno, 0, 255, "pktcdvd-char");
+ pktdev_char_major = MAJOR(devno);
+
ret = pkt_sysfs_init();
if (ret)
goto out;
@@ -3117,6 +3126,8 @@ static void __exit pkt_exit(void)
pkt_debugfs_cleanup();
pkt_sysfs_cleanup();
+ unregister_chrdev_region(MKDEV(pktdev_char_major, 0), 255);
+
unregister_blkdev(pktdev_major, DRIVER_NAME);
mempool_destroy(psd_pool);
}
Kay Sievers <[email protected]> writes:
> On Tue, 2008-10-14 at 10:38 +0200, Kay Sievers wrote:
>> On Tue, Oct 14, 2008 at 7:27 AM, Peter Osterlund <[email protected]> wrote:
>> > Greg KH <[email protected]> writes:
>> >
>> >> Both of those should get "real" majors assigned to them. It's not ok to
>> >> randomly go grabbing major:minor numbers like this for code that is in
>> >> mainline.
>> >
>> > It's not about random grabbing. It's about getting a dynamically
>> > assigned number. The pktcdvd driver once had static numbers, but at
>> > the time when the driver was merged into the mainline kernel, dynamic
>> > numbers were considered better. Therefore I changed the driver to use
>> > dynamic numbers.
>>
>> The pktcdvd driver allocates a dynamic block major, which is fine. But
>> doesn't it use the same number, and now not allocated, for the char
>> devices it uses? That looks like something that needs to fixed, right?
>>
>> static void pkt_sysfs_dev_new(struct pktcdvd_device *pd)
>> {
>> if (class_pktcdvd) {
>> pd->dev = device_create_drvdata(class_pktcdvd, NULL,
>> pd->pkt_dev, NULL,
>> "%s", pd->name);
>
> Something similar to this, with error checking, might be needed. It has
> two independent majors now in block and char:
> $ grep pkt /proc/devices
> 251 pktcdvd-char
> 252 pktcdvd
Maybe, but that character device would not be used for anything,
besides creating sub-directories in /sys/class/pktcdvd. The driver
implements a block device, not a character device.
Is it possible to create a custom directory in sysfs corresponding to
a block device? A directory /sys/block/pktcdvd0 is apparently created
automatically, but is it possible to extend that directory with driver
specific data?
--
Peter Osterlund - [email protected]
http://web.telia.com/~u89404340
On Tue, Oct 14, 2008 at 9:53 PM, Peter Osterlund <[email protected]> wrote:
> Kay Sievers <[email protected]> writes:
>> On Tue, 2008-10-14 at 10:38 +0200, Kay Sievers wrote:
>>> On Tue, Oct 14, 2008 at 7:27 AM, Peter Osterlund <[email protected]> wrote:
>>> > Greg KH <[email protected]> writes:
>>> >
>>> >> Both of those should get "real" majors assigned to them. It's not ok to
>>> >> randomly go grabbing major:minor numbers like this for code that is in
>>> >> mainline.
>>> >
>>> > It's not about random grabbing. It's about getting a dynamically
>>> > assigned number. The pktcdvd driver once had static numbers, but at
>>> > the time when the driver was merged into the mainline kernel, dynamic
>>> > numbers were considered better. Therefore I changed the driver to use
>>> > dynamic numbers.
>>>
>>> The pktcdvd driver allocates a dynamic block major, which is fine. But
>>> doesn't it use the same number, and now not allocated, for the char
>>> devices it uses? That looks like something that needs to fixed, right?
>>>
>>> static void pkt_sysfs_dev_new(struct pktcdvd_device *pd)
>>> {
>>> if (class_pktcdvd) {
>>> pd->dev = device_create_drvdata(class_pktcdvd, NULL,
>>> pd->pkt_dev, NULL,
>>> "%s", pd->name);
>>
>> Something similar to this, with error checking, might be needed. It has
>> two independent majors now in block and char:
>> $ grep pkt /proc/devices
>> 251 pktcdvd-char
>> 252 pktcdvd
>
> Maybe, but that character device would not be used for anything,
> besides creating sub-directories in /sys/class/pktcdvd. The driver
> implements a block device, not a character device.
Ah, if the char device nodes are dead anyway, care to change it to
MKDEV(0, 0), so we get rid of the warnings? This should also go into
-stable I guess, after it's fixed in the current tree.
> Is it possible to create a custom directory in sysfs corresponding to
> a block device? A directory /sys/block/pktcdvd0 is apparently created
> automatically, but is it possible to extend that directory with driver
> specific data?
A named (will automatically created in a subdir) sysfs attribute group
below the block device maybe?
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=include/linux/sysfs.h;h=37fa24152bd810f7d9dd67b685e738179b5bfdf9;hb=HEAD#l33
Thanks,
Kay