1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

USB 2.0 Hub plugged to the NAS200

Discussion in 'Cisco/Linksys Network Storage Devices' started by jackito, Dec 16, 2009.

  1. jackito

    jackito LI Guru Member

    Hi guys,

    Did anybody try this?
    I was wondering if it would be possible to plug a USB 2.0 hub to one of the ports of the NAS200 (currently one is used permanently for my USB fs :) )and then to plug, let´s say, two or three hard drives to connect USB drives?
    I know that the USB will be slow for regular data transfer but what about unnatended backups, LVM testing or just for fun. :tongue:

    Jackito
     
  2. Treah

    Treah Addicted to LI Member

    I don't see why it would not work since its running a 2.6.19 kernel. I don't know if it would be something that would work in the html admin page.
     
  3. jac_goudsmit

    jac_goudsmit Super Moderator Staff Member Member

    I'm pretty sure Sercomm/Linksys uses a non-standard way to detect (i.e. assign device ID's to) USB devices and it doesn't enumerate hubs... Sorry...

    But I know you're looking at the kernel code, so you can fix it, right? :wink:

    ===Jac
     
  4. jackito

    jackito LI Guru Member

    So trial and error it´s gonna be! :tongue:
    I have an old USB 1.1 hub that I can plug to see what happens.

    About looking at the kernel code, jac, I´m not that good! :frown:
     
  5. jackito

    jackito LI Guru Member

    Ok. After the test I have good news and bad news.

    Good news: the kernel is capable of handling a USB hub connected to the USB port. :biggrin: It seems to be correctly identifying the ports and so on.

    Bad news: it seems that the freaks working at Linksh!t tweak the kernel in some way that it doesn´t matter how many USB drives you connect to the USB hub it will always try to assign them the sdd device id (if you connect the hub to port 2, sdc if you connect it on port 1). So after connecting a second drive the kernel will complain about assigning two devices the same id and then it will "kill that port" in a way that it will not recognize anything you connect (stops scanning for new devices) until the next reboot.

    I´m publishing the trace from /var/log/messages, maybe somebody will be able to find a workaround for this.

    BTW: thanks Linksys for all this stupid tweaks (fan control + usb device id assignment) to the kernel that makes our life easier. :mad:

    Code:
    Dec 16 22:35:38 NAS200 user.warn kernel: Fan is on.
    Dec 16 22:36:15 NAS200 user.warn kernel: Interrupt 6 is received
    Dec 16 22:36:15 NAS200 user.warn kernel: Device on USB Port 2 was ejected
    Dec 16 22:36:37 NAS200 user.info kernel: usb 1-1: USB disconnect, address 2
    Dec 16 22:37:03 NAS200 user.info kernel: ohci_hcd 0000:00:0a.0: auto-wakeup
    Dec 16 22:37:04 NAS200 user.info kernel: usb 2-1: new full speed USB device using ohci_hcd and address 2
    Dec 16 22:37:04 NAS200 user.info kernel: usb 2-1: configuration #1 chosen from 1 choice
    Dec 16 22:37:04 NAS200 user.info kernel: hub 2-1:1.0: USB hub found
    Dec 16 22:37:04 NAS200 user.info kernel: hub 2-1:1.0: 4 ports detected
    Dec 16 22:38:02 NAS200 user.info kernel: usb 2-1.4: new full speed USB device using ohci_hcd and address 3
    Dec 16 22:38:02 NAS200 user.info kernel: usb 2-1.4: not running at top speed; connect to a high speed hub
    Dec 16 22:38:02 NAS200 user.info kernel: usb 2-1.4: configuration #1 chosen from 1 choice
    Dec 16 22:38:02 NAS200 user.info kernel: scsi4 : SCSI emulation for USB Mass Storage devices
    Dec 16 22:38:02 NAS200 user.warn kernel: ++++++++++++++++++++31
    Dec 16 22:38:02 NAS200 user.debug kernel: usb-storage: device found at 3
    Dec 16 22:38:02 NAS200 user.debug kernel: usb-storage: waiting for device to settle before scanning
    Dec 16 22:38:07 NAS200 user.notice kernel: scsi 4:0:0:0: Direct-Access     WDC WD16 00BB-00RDA0      20.0 PQ: 0 ANSI: 0
    Dec 16 22:38:07 NAS200 user.warn kernel: sdp->host->port=31
    Dec 16 22:38:07 NAS200 user.warn kernel: sdp->host->host_no=4
    Dec 16 22:38:07 NAS200 user.notice kernel: SCSI device sdd: 312581807 512-byte hdwr sectors (160042 MB)
    Dec 16 22:38:07 NAS200 user.notice kernel: sdd: Write Protect is off
    Dec 16 22:38:07 NAS200 user.debug kernel: sdd: Mode Sense: 03 00 00 00
    Dec 16 22:38:07 NAS200 user.err kernel: sdd: assuming drive cache: write through
    Dec 16 22:38:07 NAS200 user.notice kernel: SCSI device sdd: 312581807 512-byte hdwr sectors (160042 MB)
    Dec 16 22:38:07 NAS200 user.notice kernel: sdd: Write Protect is off
    Dec 16 22:38:07 NAS200 user.debug kernel: sdd: Mode Sense: 03 00 00 00
    Dec 16 22:38:07 NAS200 user.err kernel: sdd: assuming drive cache: write through
    Dec 16 22:38:07 NAS200 user.info kernel:  sdd: sdd1
    Dec 16 22:38:07 NAS200 user.notice kernel: sd 4:0:0:0: Attached scsi disk sdd
    Dec 16 22:38:07 NAS200 user.notice kernel: sd 4:0:0:0: Attached scsi generic sg2 type 0
    Dec 16 22:38:07 NAS200 user.debug kernel: usb-storage: device scan complete
    Dec 16 22:40:41 NAS200 user.warn kernel: Fan is on.
    Dec 16 22:41:32 NAS200 user.info kernel: usb 2-1.3: new full speed USB device using ohci_hcd and address 4
    Dec 16 22:41:32 NAS200 user.info kernel: usb 2-1.3: not running at top speed; connect to a high speed hub
    Dec 16 22:41:32 NAS200 user.info kernel: usb 2-1.3: configuration #1 chosen from 1 choice
    Dec 16 22:41:32 NAS200 user.info kernel: scsi5 : SCSI emulation for USB Mass Storage devices
    Dec 16 22:41:32 NAS200 user.warn kernel: ++++++++++++++++++++31
    Dec 16 22:41:32 NAS200 user.debug kernel: usb-storage: device found at 4
    Dec 16 22:41:32 NAS200 user.debug kernel: usb-storage: waiting for device to settle before scanning
    Dec 16 22:41:37 NAS200 user.notice kernel: scsi 5:0:0:0: Direct-Access     SanDisk  Cruzer Micro     8.02 PQ: 0 ANSI: 0 CCS
    Dec 16 22:41:37 NAS200 user.warn kernel: sdp->host->port=31
    Dec 16 22:41:37 NAS200 user.warn kernel: sdp->host->host_no=5
    Dec 16 22:41:37 NAS200 user.notice kernel: SCSI device sdd: 15695871 512-byte hdwr sectors (8036 MB)
    Dec 16 22:41:38 NAS200 user.notice kernel: sdd: Write Protect is off
    Dec 16 22:41:38 NAS200 user.debug kernel: sdd: Mode Sense: 45 00 00 08
    Dec 16 22:41:38 NAS200 user.err kernel: sdd: assuming drive cache: write through
    Dec 16 22:41:38 NAS200 user.warn kernel: kobject_add failed for sdd with -EEXIST, don't try to register things with the same name in the same directory.
    Dec 16 22:41:38 NAS200 user.warn kernel:  [<c023f902>] kobject_add+0xfb/0x104
    Dec 16 22:41:38 NAS200 user.warn kernel:  [<c0187a6d>] register_disk+0x40/0x125
    Dec 16 22:41:38 NAS200 user.warn kernel:  [<c0238c15>] add_disk+0x36/0x41
    Dec 16 22:41:38 NAS200 user.warn kernel:  [<c0238bca>] exact_match+0x0/0x4
    Dec 16 22:41:38 NAS200 user.warn kernel:  [<c0238bce>] exact_lock+0x0/0x11
    Dec 16 22:41:38 NAS200 user.warn kernel:  [<c029cdb8>] sd_probe+0x265/0x323
    Dec 16 22:41:38 NAS200 user.warn kernel:  [<c028c1da>] really_probe+0x38/0xd8
    Dec 16 22:41:38 NAS200 user.warn kernel:  [<c028c330>] driver_probe_device+0x9e/0xaa
    Dec 16 22:41:38 NAS200 user.warn kernel:  [<c034cffc>] klist_next+0x5a/0x72
    Dec 16 22:41:38 NAS200 user.warn kernel:  [<c028c33c>] __device_attach+0x0/0x5
    Dec 16 22:41:38 NAS200 user.warn kernel:  [<c028b95f>] bus_for_each_drv+0x39/0x5d
    Dec 16 22:41:38 NAS200 user.warn kernel:  [<c028c39f>] device_attach+0x5e/0x78
    Dec 16 22:41:38 NAS200 user.warn kernel:  [<c028c33c>] __device_attach+0x0/0x5
    Dec 16 22:41:38 NAS200 user.warn kernel:  [<c028bb13>] bus_attach_device+0x1e/0x3e
    Dec 16 22:41:38 NAS200 user.warn kernel:  [<c028a7d2>] device_add+0x248/0x395
    Dec 16 22:41:38 NAS200 user.warn kernel:  [<c0299ff1>] scsi_sysfs_add_sdev+0x27/0x148
    Dec 16 22:41:38 NAS200 user.warn kernel:  [<c029893e>] scsi_add_lun+0x2cb/0x2dd
    Dec 16 22:41:38 NAS200 user.warn kernel:  [<c0298a9f>] scsi_probe_and_add_lun+0x14f/0x1e7
    Dec 16 22:41:38 NAS200 user.warn kernel:  [<c02991da>] __scsi_scan_target+0xa6/0xe9
    Dec 16 22:41:38 NAS200 user.warn kernel:  [<c02992e7>] scsi_scan_channel+0x4f/0x81
    Dec 16 22:41:38 NAS200 user.warn kernel:  [<c0299386>] scsi_scan_host_selected+0x6d/0x9e
    Dec 16 22:41:38 NAS200 user.warn kernel:  [<c02993d3>] scsi_scan_host+0x1c/0x1f
    Dec 16 22:41:38 NAS200 user.warn kernel:  [<c02cdf09>] usb_stor_scan_thread+0x127/0x14a
    Dec 16 22:41:38 NAS200 user.warn kernel:  [<c01267ab>] autoremove_wake_function+0x0/0x33
    Dec 16 22:41:38 NAS200 user.warn kernel:  [<c02cdde2>] usb_stor_scan_thread+0x0/0x14a
    Dec 16 22:41:38 NAS200 user.warn kernel:  [<c0126441>] kthread+0x78/0x9d
    Dec 16 22:41:38 NAS200 user.warn kernel:  [<c01263c9>] kthread+0x0/0x9d
    Dec 16 22:41:38 NAS200 user.warn kernel:  [<c0103097>] kernel_thread_helper+0x7/0x10
    Dec 16 22:41:38 NAS200 user.warn kernel:  =======================
    Dec 16 22:41:38 NAS200 user.alert kernel: BUG: unable to handle kernel NULL pointer dereference at virtual address 00000018
    Dec 16 22:41:38 NAS200 user.alert kernel:  printing eip:
    Dec 16 22:41:38 NAS200 user.warn kernel: c018a9a6
    Dec 16 22:41:38 NAS200 user.alert kernel: *pde = 00000000
    Dec 16 22:41:38 NAS200 user.emerg kernel: Oops: 0000 [#1]
    Dec 16 22:41:38 NAS200 user.warn kernel: Modules linked in: iscsi_trgt crc32c(F) libcrc32c(F) bridge(F) llc(F) tun(F) nls_cp950 nls_cp949 nls_cp932 pbuttons(P)
    Dec 16 22:41:38 NAS200 user.emerg kernel: CPU:    0
    Dec 16 22:41:38 NAS200 user.emerg kernel: EIP:    0060:[<c018a9a6>]    Tainted: PF     VLI
    Dec 16 22:41:38 NAS200 user.emerg kernel: EFLAGS: 00000282   (2.6.19 #88)
    Dec 16 22:41:38 NAS200 user.emerg kernel: EIP is at create_dir+0xf/0x194
    Dec 16 22:41:38 NAS200 user.emerg kernel: eax: c1393a60   ebx: c1393a60   ecx: c1393a64   edx: 00000000
    Dec 16 22:41:38 NAS200 user.emerg kernel: esi: 00000000   edi: c0050110   ebp: c00500c0   esp: c14c7d1c
    Dec 16 22:41:38 NAS200 user.emerg kernel: ds: 007b   es: 007b   ss: 0068
    Dec 16 22:41:38 NAS200 user.emerg kernel: Process usb-stor-scan (pid: 4857, ti=c14c6000 task=c1bc8ab0 task.ti=c14c6000)
    Dec 16 22:41:38 NAS200 user.emerg kernel: Stack: c036b763 c14c7d2c 00000000 c1393a60 c1393a60 00000000 c0050110 c00500c0 
    Dec 16 22:41:38 NAS200 user.emerg kernel:        c018ab90 c14c7d44 00000000 c1393a60 c023f6bb c1393a60 c1393938 c023f8b8 
    Dec 16 22:41:38 NAS200 user.emerg kernel:        00000001 c00500c0 c0187a6d c00500c0 c00500cc c1393938 c1393a60 c0238191 
    Dec 16 22:41:38 NAS200 user.emerg kernel: Call Trace:
    Dec 16 22:41:38 NAS200 user.emerg kernel:  [<c018ab90>] sysfs_create_dir+0x51/0x64
    Dec 16 22:41:38 NAS200 user.emerg kernel:  [<c023f6bb>] create_dir+0x10/0x2f
    Dec 16 22:41:38 NAS200 user.emerg kernel:  [<c023f8b8>] kobject_add+0xb1/0x104
    Dec 16 22:41:38 NAS200 user.emerg kernel:  [<c0187a6d>] register_disk+0x40/0x125
    Dec 16 22:41:38 NAS200 user.emerg kernel:  [<c0238191>] blk_register_queue+0x32/0x6a
    Dec 16 22:41:38 NAS200 user.emerg kernel:  [<c029cdb8>] sd_probe+0x265/0x323
    Dec 16 22:41:38 NAS200 user.emerg kernel:  [<c028c1da>] really_probe+0x38/0xd8
    Dec 16 22:41:38 NAS200 user.emerg kernel:  [<c028c330>] driver_probe_device+0x9e/0xaa
    Dec 16 22:41:38 NAS200 user.emerg kernel:  [<c034cffc>] klist_next+0x5a/0x72
    Dec 16 22:41:38 NAS200 user.emerg kernel:  [<c028c33c>] __device_attach+0x0/0x5
    Dec 16 22:41:38 NAS200 user.emerg kernel:  [<c028b95f>] bus_for_each_drv+0x39/0x5d
    Dec 16 22:41:38 NAS200 user.emerg kernel:  [<c028c39f>] device_attach+0x5e/0x78
    Dec 16 22:41:38 NAS200 user.emerg kernel:  [<c028c33c>] __device_attach+0x0/0x5
    Dec 16 22:41:38 NAS200 user.emerg kernel:  [<c028bb13>] bus_attach_device+0x1e/0x3e
    Dec 16 22:41:38 NAS200 user.emerg kernel:  [<c028a7d2>] device_add+0x248/0x395
    Dec 16 22:41:38 NAS200 user.emerg kernel:  [<c0299ff1>] scsi_sysfs_add_sdev+0x27/0x148
    Dec 16 22:41:38 NAS200 user.emerg kernel:  [<c029893e>] scsi_add_lun+0x2cb/0x2dd
    Dec 16 22:41:38 NAS200 user.emerg kernel:  [<c0298a9f>] scsi_probe_and_add_lun+0x14f/0x1e7
    Dec 16 22:41:38 NAS200 user.emerg kernel:  [<c02991da>] __scsi_scan_target+0xa6/0xe9
    Dec 16 22:41:38 NAS200 user.emerg kernel:  [<c02992e7>] scsi_scan_channel+0x4f/0x81
    Dec 16 22:41:38 NAS200 user.emerg kernel:  [<c0299386>] scsi_scan_host_selected+0x6d/0x9e
    Dec 16 22:41:38 NAS200 user.emerg kernel:  [<c02993d3>] scsi_scan_host+0x1c/0x1f
    Dec 16 22:41:38 NAS200 user.emerg kernel:  [<c02cdf09>] usb_stor_scan_thread+0x127/0x14a
    Dec 16 22:41:38 NAS200 user.emerg kernel:  [<c01267ab>] autoremove_wake_function+0x0/0x33
    Dec 16 22:41:38 NAS200 user.emerg kernel:  [<c02cdde2>] usb_stor_scan_thread+0x0/0x14a
    Dec 16 22:41:38 NAS200 user.emerg kernel:  [<c0126441>] kthread+0x78/0x9d
    Dec 16 22:41:38 NAS200 user.emerg kernel:  [<c01263c9>] kthread+0x0/0x9d
    Dec 16 22:41:38 NAS200 user.emerg kernel:  [<c0103097>] kernel_thread_helper+0x7/0x10
    Dec 16 22:41:38 NAS200 user.emerg kernel:  =======================
    Dec 16 22:41:38 NAS200 user.emerg kernel: Code: 00 00 c7 80 b8 00 00 00 e0 4a 35 c0 31 c0 c3 c7 80 b4 00 00 00 20 98 3c c0 31 c0 c3 55 57 56 53 83 ec 10 89 54 24 08 89 44 24 0c <8b> 42 18 89 cb 83 c0 7c 8b 6c 24 24 89 df e8 e7 38 1c 00 31 c0 
    Dec 16 22:41:38 NAS200 user.emerg kernel: EIP: [<c018a9a6>] create_dir+0xf/0x194 SS:ESP 0068:c14c7d1c
    
     
  6. Treah

    Treah Addicted to LI Member

    I am almost tempted to just build a vanilla kernel load it up and see what happens. I expect catastrophic failure. I think if we work on the kernel a bit we can get something that loads up on the nas alright and eliminates some of the silliness. I wouldn't mind losing the web interface either as long as I had ssh access. There are a ton of other web admin stuff out there anyway. When im not being a lazy bastard ill take a better look at the kernel and at what jac figured out and see if I cant wrangle this beast into something a bit more workable.
     
  7. jac_goudsmit

    jac_goudsmit Super Moderator Staff Member Member

     
  8. jackito

    jackito LI Guru Member

    I´m not that dissappointed with the stock kernel in the NAS200.
    I just think that they shouldn´t patch or hardcode some things in the kernel as they did (fan + usb handling), becasue I don´t see the point. But who knows, maybe they ned to do it like that to make the whole thing work.

    I agree with your approach Jac, regarding your firmware, because I didn´t really wanted to loose some of the stock features, like the web interface and so on. And I´m using the same approach to finish my USB root fs.
    All the basic features will be there plus a lot more. :biggrin:

    Anyway if the user wants to load a custom kernel, he is free to do it with tools like kexec.

    About the main idea of this thread, I would like to make the USB hub with two or three harddrives work, so probably I will start to work on it after finishing the USB root fs (maybe this weekend).
     
  9. jackito

    jackito LI Guru Member

    BTW any volunteers to join me messing with the SCSI layer of the NAS200 Linux kernel? Just to take a look to the device assignment mechanism, that seems to be the prime suspect. :cool:
     
  10. jac_goudsmit

    jac_goudsmit Super Moderator Staff Member Member

    At the time when Sercomm started developing the firmware, there was no support for the RDC CPU in the kernel so there was no way to use a standard vanilla kernel. They had no choice but to hardcode things like chipset initialization and LED control through GPIO.

    Other things such as support for the RDC Network interface probably came straight from a Board Support Package by RDC, and I know how those are usually made: hardware manufacturers don't usually want to spend much time and money on software so they put something together (preferably from existing code) and modify it just enough to make it work, and leave it at that. Optimization is left to the customer (in this case, Linksys and Sercomm). There's nothing wrong with that, because chip manufacturers in most cases have no idea how the chips are going to be integrated into a system. But nowadays system integrators are probably forced to take many shortcuts due to time constraints, and they have no choice but to reuse the sample code.

    ===Jac
     
  11. jac_goudsmit

    jac_goudsmit Super Moderator Staff Member Member

    Here's Part 1 of a list of changes to the kernel. I used my nasi200 project SVN database to find this information but you can easily reproduce this from a diff too.

    This goes from the root of the tree down alphabetically and includes everything up to and including the drivers/ directory.

    • arch/i386/kernel/syscall_table.S Added syscalls for gpio
    • drivers/ata/libata-sff.c Added code to blink LEDs during harddisk access and turn fan on
    • drives/base/core.c Added code to show device registration (minor change)
    • drivers/char/rtc.c Replaced the rtc.c module with code for the Intersil X1226. This should really have been added as a separate module, this was clearly a quick-and-very-dirty change. Note that the X1226 is apparently not actually in use, see below.
    • drivers/i2c/ (tree) Many changes. It looks like they patched the kernel for a Velleman K8000 electronics kit that uses I2C bitbanging on the parallel port, but they used a patch for an older kernel version which makes it generate a lot of compiler warnings but apparently it still works.
    • drivers/input/serio/Makefile Commented out the 8042 keyboard controller driver (there's no reason to do it this way, they could have just disabled it in the config)
    • drivers/mtd/chips/cfi_cmdset_0001.c Change in erase code for MTD devices
    • drivers/mtd/maps/physmap.c Replaced pretty much entire module to accomplish hardcoded partitioning of the flash ROM
    • drivers/mtd/mtdblock.c Changed some function calls into macro calls, possibly just for debugging
    • drivers/mtd/mtdblock_ro.c Same
    • drivers/mtd/mtdchar.c Added a bunch of code, looks like this is mostly for debugging
    • drivers/net/Makefile Hacked in the RDC R6040 Network Interface Controller module
    • drivers/net/r6040.c Added RDC R6040 NIC module. Note, the code in this module appears to be very old (v0.9, 2005), the mainline kernel now has this module in the tree but the code in the mainline kernel is very different and much newer; obviously I recommend using the code from the kernel disregarding this patch
    • drivers/rtc/Makefile hacked in the rtc-s3530a.c module
    • drivers/rtc/rtc-s3530a.c Added this module. I don't know why both the Intersil X1226 and the Seiko S3530A have modules in the kernel, maybe they are interchangeable or maybe one of them is not in use but was added to the kernel for a previous project (NSLU2?) or for a previous hardware version that was never released, and nobody bothered to take it out. From this picture it looks like the S3530A is the one that's actually in use (it's near the battery in the bottom left of the picture).
    • drivers/scsi/Makefile Some modules were hacked in, then commented out again. I think there were some big changes to the kernel going on around the time when 2.6.19 came out, where the architecture was changed so that SATA was handled more like SCSI than IDE, and it looks like this is part of a patch that was applied and is now part of the mainline kernel. It took me a while to figure out how to configure the 2.6.27 kernel to detect the hard disks, this is probably why. Still, strange that the sata_sil.c module doesn't appear to be in use...
    • drivers/scsi/libata.h Added, probably part of some SATA patch
    • drivers/scsi/sata_sil.c Added module for Silicon Image SATA controllers, this is now supported in the mainline kernel
    • drivers/scsi/sata_sil24.c Added module for Silicon Image SATA controllers, this is now supported in the mainline kernel (this module is not actually needed, it's probably part of a bigger patch)
    • drivers/scsi/scsi_proc.c Small change, for debugging only
    • drivers/scsi/sd.c Many changes to assign sd* names to USB devices. This module is where your problem is, I bet it's caused by the block of code at line 1703.. They were probably forced to assign names this (ugly) way because their automatic mounter (and maybe the program that broadcasts to the PC utility) may be hard-coded to use sd* devices. This is clearly a quick-and-dirty solution to some problem they had.
    • drivers/usb/storage/transport.c Changed to control the LEDs for USB storage devices
    • drivers/usb/storage/usb.c Minor change to generate debug output
    • drivers/Makefile Hack to build I2C before RTC

    I'll try to generate the rest of the list later, I ran out of time.

    ===Jac
     
  12. jackito

    jackito LI Guru Member

    Jac, thanks a lot for this info it´s really usefull (and I´m amazed that you taked the time to compare and understand the differences between the sources).

    I searched for the code in the kernel source, and tried to understand it. It´s quite short and should be quite simple BUT since I know nothing about C I couldn´t manage to understand it. I´m really frustrated. :frown:

    Again, thanks a lot.
    With some time (and learning some C) probably I will understand it and manage to do the small (¿?) change I need.
     
  13. Treah

    Treah Addicted to LI Member

    i just got done reading your previous post. From what I could gather you actually did get the ethernet port working it was more of a stupid DHCP issue and the startup scripts from gentoo that failed. I wonder if you couldn't get redboot to chainload grub and then have that load up a kernel from somewhere on the hard disk. Grub2 would be more helpfull since I think you can do all sorts of crazy stuff with it.
     
  14. jac_goudsmit

    jac_goudsmit Super Moderator Staff Member Member

    No, the network never worked with the Gentoo kernel. If I remember correctly, according to the Googles, the SIOCSIFFLAGS error indicates that there's something wrong with the PHY drivers (basically, the R6040 driver is unable to set the MAC address IIRC). I never dug down any further to see what was happening but I seem to remember it has something to do with the fact that the NAS200's MAC address is stored in flash and the mainline kernel doesn't know what to set it to, or sets it to an invalid default value like ff:ff:ff:ff:ff:ff. Some day I'll figure it out -- if Sercomm and OpenWRT can do it, so can I :wink:

    Grub probably won't work because I expect that it uses the BIOS to load the OS from disk, and there is no BIOS in the NAS200. Okay there's a BIOS available for the RDC eval board but that probably can't be used because it depends on the eval board hardware and you would need a video card and keyboard. We could use OpenBIOS but it's probably more work than it's worth.

    But I do agree that it would be awesome if it were possible to let Redboot do some of the magic. I'm thinking of e.g storing a string in the MBR that tells a modified Redboot where to load the kernel and optional initrd (the MBR is only used for the partition table anyway, there's no need for executable code in there so plenty of space left). We can use the backup button on the front panel to override: holding the backup button down while booting will always boot the ROM no matter what's in the MBR config.

    So many ideas, so little time...

    ===Jac
     
  15. jackito

    jackito LI Guru Member

    Hi,

    I´m working again on this issue of the SCSI disk letter assignment, that is fixed in the kernel of the NAS200, depending on which port the disk (or USB flash drive) is connected. My goal is to leave on USB port as is, but allow to connect more than one USB drive to the other one, using a USB hub.
    So far I connected a printer, a scanner and one USB drive to the hub and everything is working fine. But still with the limitation of one USB drive per USB port, that I want to get rid off.

    I edited the drivers/scsi/sd.c.
    In sd.c line 1638 I replaced this:

    Code:
            if(sdp->host->port==0x31)
                    index=2;
            else if(sdp->host->port==0x32)
                    index=1;
            else
                    index=0;
    
    With this:

    Code:
            if(sdp->host->port==0x31)
                    //index=2;
                    if (!idr_pre_get(&sd_index_idr, GFP_KERNEL))
                            goto out_put;
    
                    spin_lock(&sd_index_lock);
                    error = idr_get_new_above(&sd_index_idr, NULL, 2, &index);
                    spin_unlock(&sd_index_lock);
    
                    if (index >= SD_MAX_DISKS)
                            error = -EBUSY;
                    if (error)
                            goto out_put;
            else if(sdp->host->port==0x32)
                    index=1;
            else
                    index=0;
    
    And in line 1715, I replaced this:

    Code:
            if(!index){
                    gd->major = 8;
                    gd->first_minor = 0 + 16*sdp->host->host_no;
                    gd->minors = 16;
                    gd->fops = &sd_fops;
                    sprintf(gd->disk_name, "sd%c", 'a' + sdp->host->host_no);
            }
            else {
                    gd->major = 8;
                    gd->first_minor = 0 + 16*(index+1);
                    gd->minors = 16;
                    gd->fops = &sd_fops;
                    sprintf(gd->disk_name, "sd%c", 'a' + (index+1));
            }
    
    With this:

    Code:
            if(!index){
                    gd->major = 8;
                    gd->first_minor = 0 + 16*sdp->host->host_no;
                    gd->minors = 16;
                    gd->fops = &sd_fops;
                    sprintf(gd->disk_name, "sd%c", 'a' + sdp->host->host_no);
            }
            else if(index==1){
                    gd->major = 8;
                    gd->first_minor = 0 + 16*(index+1);
                    gd->minors = 16;
                    gd->fops = &sd_fops;
                    sprintf(gd->disk_name, "sd%c", 'a' + (index+1));
            }
            else{
                    gd->major = sd_major((index & 0xf0) >> 4);
                    gd->first_minor = ((index & 0xf) << 4) | (index & 0xfff00);
                    gd->minors = 16;
                    gd->fops = &sd_fops;
    
                    if (index < 26) {
                            sprintf(gd->disk_name, "sd%c", 'a' + index % 26);
                    } else if (index < (26 + 1) * 26) {
                            sprintf(gd->disk_name, "sd%c%c",
                                    'a' + index / 26 - 1,'a' + index % 26);
                    } else {
                            const unsigned int m1 = (index / 26 - 1) / 26 - 1;
                            const unsigned int m2 = (index / 26 - 1) % 26;
                            const unsigned int m3 =  index % 26;
                            sprintf(gd->disk_name, "sd%c%c%c",
                                    'a' + m1, 'a' + m2, 'a' + m3);
                    }
            }
    
    Then I compiled successfully (without warning or compile errors at all) the new kernel with "make bzImage". Copied it to the NAS200 and try to boot it, of course it didn´t work.
    The problem is that I don´t have a JTAG to connect to the serial port and check the kernel messages to see what´s wrong. :frown:
    I tried with netconsole, but it seems that this kernel is crashing very early, even before bringing up the network card.

    My C knowledge is very limited but I´m doing my best.
    The var "index" is defined as u32 (variable-length encoded 32-bit unsigned integer value) in the code. What I´m not sure about is that the original patch by Linksys is asigning a decimal integer value to "index" and in my modification I think that idr_get_new_above() is assigning a hexadecimal interger value to this variable. Am I right?
    If somebody can check the code and find the errors it would be great. :)
    Also if somebody with a JTAG would like to test this kernel and share de console output to see the problem it would be also great.
    Thanks in advances guys,

    Jackito
     
  16. jac_goudsmit

    jac_goudsmit Super Moderator Staff Member Member

    If you are hacking the kernel you really want to make sure that you won't paint yourself into a corner :)

    If you can't boot your NAS anymore you will need a serial port or you won't be able to flash something else. Once you have a serial port, you can flash a working image with Upslug.

    To prevent it from happening again, just flash Jac4 into the NAS. You can then use kexec to load a different kernel. My kernel supports this, there's just no kexec program in the image so you'll have to get it from another x86 distro.

    If I recall correctly, you simply do kexec -l /path/to/bzImage and then kexec -e to start it (you will have to set the startup options somehow too, I forgot how this works and I don't have time to look it up; Google is your friend). If the new kernel doesn't work, all you need to do is unplug the box and plug it back in to boot the (known working) kernel from Flash; lather, rinse, repeat.

    Either way, to follow the output of the kernel and see any panics, you will have to connect something to the console, and the console is the serial port. A 3.3V serial port to USB converter shouldn't be hard to find on the Internet, and nslu2-linux.org has the pinout for the serial connector on the motherboard (the NAS200 and NSLU2 connectors are identical).

    A serial port is not the same as JTAG by the way. You will only need a JTAG connector (and the RDC debugging tool) if you wipe the boot loader. DON'T USE THE "FLASH" COMMAND IN THE REDBOOT COMMAND PROMPT! This erases the boot loader and the only way to fix it is JTAG and it's not easy!

    ===Jac
     
  17. jackito

    jackito LI Guru Member

    Hi jac,

    Thanks for the advice but this is not the case. My NAS200 is up and running since as you suggested I´m using kexec to launch the custom kernel. Everytime it fails, I just restart the NAS200 and that´s all. :wink:
    About the serial console, I will search for the pinouts and so on, I tought that it was the same as JTAG. :redface:

    Jackito
     
  18. jackito

    jackito LI Guru Member

    I´m happy to announce that I succeded to modify the kernel and enable more than one USB disc per USB port on the NAS200. :biggrin:

    After building a cable to access the console, I saw the kernel panic. Fix my modification and compile again.
    This time is working fine:

    Code:
    root@NAS200 ~# fdisk -l
    
    Disk /dev/sda: 255 heads, 63 sectors, 77825 cylinders
    Units = cylinders of 16065 * 512 bytes
    
       Device Boot    Start       End    Blocks   Id  System
    /dev/sda1             1     77780 624767818+  fd  Linux raid autodetect
    /dev/sda2         77781     77810    240975   fd  Linux raid autodetect
    /dev/sda3         77811     77825    120487+  82  Linux swap
    
    Disk /dev/sdb: 255 heads, 63 sectors, 77825 cylinders
    Units = cylinders of 16065 * 512 bytes
    
       Device Boot    Start       End    Blocks   Id  System
    /dev/sdb1             1     77780 624767818+  fd  Linux raid autodetect
    /dev/sdb2         77781     77810    240975   fd  Linux raid autodetect
    /dev/sdb3         77811     77825    120487+  82  Linux swap
    
    Disk /dev/sdc: 124 heads, 62 sectors, 1018 cylinders
    Units = cylinders of 7688 * 512 bytes
    
       Device Boot    Start       End    Blocks   Id  System
    /dev/sdc1             2      1019   3910720    c  Win95 FAT32 (LBA)
    Partition 1 has different physical/logical beginnings (non-Linux?):
         phys=(15, 1, 12) logical=(1, 6, 5)
    Partition 1 has different physical/logical endings:
         phys=(940, 4, 32) logical=(1018, 50, 20)
    Partition 1 does not end on cylinder boundary:
         phys=(940, 4, 32) should be (940, 123, 62)
    
    Disk /dev/sdd: 255 heads, 63 sectors, 121601 cylinders
    Units = cylinders of 16065 * 512 bytes
    
       Device Boot    Start       End    Blocks   Id  System
    /dev/sdd1             1     77804 624960598+  83  Linux
    /dev/sdd2         77805    121601 351799402+  8e  Linux LVM
    
    Disk /dev/sde: 255 heads, 63 sectors, 19457 cylinders
    Units = cylinders of 16065 * 512 bytes
    
       Device Boot    Start       End    Blocks   Id  System
    /dev/sde1             1     19457 156288352   8e  Linux LVM
    
    /dev/sdd and /dev/sde are connected to a USB hub on one of the USB ports in the NAS200.
    I´m 95% happy with the solution althrough I found a problem that can be annoying and I will try to correct soon.
    Every time you connect a USB disc to the NAS200 it will get a new host number instead of re-using a free one. This way if you unplug and then plug again the same USB disk, you will see that instead of getting the same device id (for instance /dev/sde) it will get a new device id, increased by one (/dev/sdf using the previous example). It´s annoying but fixeable I think. I just need to investigate a little more the code.

    Jackito

    PS: now pluggin more discs I´m able to play with LVM without risking my RAID-1 configuration. :cool:
     
  19. jac_goudsmit

    jac_goudsmit Super Moderator Staff Member Member

    That's great news Jackito!

    Do you know if the Linksys software would still automatically mount and share a USB device if you would plug it in?

    (Not that it matters, there are ways to do this with open source software too)

    I'm not very familiar with how Linux does this, but Windows keeps a list of known removable disks in the registry and tries to mount them on the same drive letter as it was mounted before if it can.

    Did you change the source back to what's originally in the Linux kernel? If you do that, it might accomplish what you (we) want...

    ===Jac
     
  20. jackito

    jackito LI Guru Member

    I will try it and update. I didn´t do it yet because all my external harddisks are running either ext3 or ext3 over LVM.

    I´m not one 100% sure but as far as I understood from the kernel sources (the unpatched original sources) the kernel is just assigning ids to each USB harddisk when you plug it and as soon as you unplug it the kernel is releasing this id for future use (by the same harddisk or not).

    About my change to kernel source, I tried to user the kernel original code but it resulted in a kernel panic when assigning the "device id" so as a workaround (because of my limited knowledge) I just changed the code to assign ids (only to devices connected to one of the USB ports) based on the scsi host number, starting from 2 (that would give the first disc id = 2 => sdd, the second id = 3 => sde and so on). It´s not the best solution, for sure, specially because every time I plug a USB drive I get a new id and of course a new device. That´s why I created device nodes under /dev from sdg to sdn. LOL!

    Again, is not the best solution but it achieves my goal since I´m not plug in and out USB harddisks all the time.

    jackito

    PS: if somebody is interested in the kernel code change, I can post it. Just let me know.
     
  21. jackito

    jackito LI Guru Member

    I tested this yesterday and it seems that Linksys firmware is only trying to "automount and share" sdc and sdd devices (if they are formated as FAT or NTFS). :rolleyes:

    jackito
     

Share This Page