sending the scapy packet as below over eth3
ans, unans = srp1(REQUEST, iface=self.iface)
print ans, unans
the call never returns, I tried srp too. (send/sendp/sniff too). I see response as None or call just hangs.
However, I could see the request and response on tcpdump just fine
listening on eth3, link-type EN10MB (Ethernet), capture size 65535 bytes
16:52:52.565683 00:26:55:27:1c:a2 (oui Unknown) > Broadcast, ethertype Unknown (0x88f8), length 34:
0x0000: ffff ffff ffff 0026 5527 1ca2 88f8 0001
0x0010: 000b 1500 0000 0000 0000 0000 0000 ffff
0x0020: eaf4
16:52:52.576476 00:04:25:1c:a0:02 (oui Unknown) > Broadcast, ethertype Unknown (0x88f8), length 76:
0x0000: ffff ffff ffff 0004 251c a002 88f8 0001
0x0010: 000b 9500 0028 0000 0000 0000 0000 0000
0x0020: 0000 f1f0 f100 0000 0000 0000 0000 0000
0x0030: 0000 0000 0000 0803 0087 1634 XXXX XXXX
0x0040: XXXX 0000 XXXX XXXX XXXX ffff
I figured it out and sharing it -
If you define new protocol with custom payloads, Answer layer should implement "answers" method:
e.g:
class MyAnswer(Packet):
name = "MyAnswer"
fields_desc = [ByteEnumField("isOk", 0. BooleanFields)]
def answers(self, other):
return isinstance(other, MyRequest)
Related
in the past week I struggled with this problem, and it seems I can't handle it finally.
Given an arbitrary 64bit unsigned int number, if it contains the binary pattern of 31 (0b11111) at any bit position, at any bit settings, the number is valid, otherwise not.
E.g.:
0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 1111 valid
0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0011 1110 valid
0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0111 1100 valid
0000 0000 0000 0000 0000 0000 0000 0000 0000 1111 1000 0000 0000 0000 0000 0000 valid
0000 0000 0011 1110 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0011 1110 valid etc...
also:
0000 0000 0000 1100 0000 0100 0000 0000 1100 1100 0000 0000 0100 0000 0001 1111 valid
1110 0000 0000 0100 0000 0000 0011 0000 0000 0000 0000 0000 0000 0000 0011 1110 valid
0000 0000 1000 0010 0000 0010 0000 0000 0000 0000 0010 0000 0000 0000 0111 1100 valid
0000 0010 0000 0110 0000 0000 0000 0000 0000 1111 1000 0000 0000 0100 0110 0000 valid
0000 0000 0011 1110 0000 0000 0011 0000 0000 1000 0000 0000 0000 0000 0011 1110 valid etc...
but:
0000 0000 0000 1100 0000 0100 0000 0000 1100 1100 0000 0000 0100 0000 0000 1111 invalid
1110 0000 0000 0100 0000 0000 0011 0000 0000 0000 0000 0000 0000 0000 0011 1100 invalid
0000 0000 1000 0010 0000 0010 0000 0000 0000 0000 0010 0000 0000 0000 0101 1100 invalid
0000 0010 0000 0110 0000 0000 0000 0000 0000 1111 0000 0000 0000 0100 0110 0000 invalid
0000 0000 0011 1010 0000 0000 0011 0000 0000 1000 0000 0000 0000 0000 0001 1110 invalid etc...
You've got the point...
But that is just the first half of the problem. The second one is, it needs to be implemented without loops or branches (which was done already) for speed increasing, using only one check by arithmetic and/or logical, bit manipulation kind of code.
The closest I can get, is a modified version of Bit Twiddling Hacks "Determine if a word has a zero byte" ( https://graphics.stanford.edu/~seander/bithacks.html#ZeroInWord ) to check five bit blocks of zeros (negated 11111). But it still has the limit of the ability to check only fixed blocks of bits (bit 0 to 4, bit 5 to 9, etc...) not at any bit position (as in the examples above).
Any help would be greatly appreciated, since I'm totally exhausted.
Sz
Implementation
Let me restate your goal in a slightly different formulation:
I want to check whether an integer contains 5 consecutive high bits.
From this formulation the following solution explains itself. It is written in C++.
bool contains11111(uint64_t i) {
return i & (i << 1) & (i << 2) & (i << 3) & (i << 4);
}
This approach also works for any other pattern. For instance, if you wanted to check for 010 you would use ~i & (i<<1) & ~(i<<2). In your example the pattern's length is a prime number, but for composite numbers and especially powers of two you can optimize this even further. For instance, when searching for 1111 1111 you could use i&=i<<1; i&=i<<2; i&=i<<4; return i.
Testing
To test this on your examples I used the following program. The literals inside testcases[] were generated by running your examples through the bash command ...
{ echo 'ibase=2'; tr -dc '01\n' < fileWithYourExamples; } |
bc | sed 's/.*/UINT64_C(&),/'
#include <cinttypes>
#include <cstdio>
bool contains11111(uint64_t i) {
return i & (i << 1) & (i << 2) & (i << 3) & (i << 4);
}
int main() {
uint64_t testcases[] = {
// valid
UINT64_C(31),
UINT64_C(62),
UINT64_C(124),
UINT64_C(260046848),
UINT64_C(17451448556060734),
UINT64_C(3382101189607455),
UINT64_C(16142027170561130558),
UINT64_C(36593945997738108),
UINT64_C(145804038196167776),
UINT64_C(17451654848708670),
// invalid
UINT64_C(3382101189607439),
UINT64_C(16142027170561130556),
UINT64_C(36593945997738076),
UINT64_C(145804038187779168),
UINT64_C(16325754941866014),
};
for (uint64_t i : testcases) {
std::printf("%d <- %016" PRIx64 "\n", contains11111(i), i);
}
}
This prints
1 <- 000000000000001f
1 <- 000000000000003e
1 <- 000000000000007c
1 <- 000000000f800000
1 <- 003e00000000003e
1 <- 000c0400cc00401f
1 <- e00400300000003e
1 <- 008202000020007c
1 <- 020600000f800460
1 <- 003e00300800003e
0 <- 000c0400cc00400f
0 <- e00400300000003c
0 <- 008202000020005c
0 <- 020600000f000460
0 <- 003a00300800001e
Good day!
I read documentation on pdf, but I have some global problems.
https://www.adobe.com/content/dam/acom/en/devnet/acrobat/pdfs/PDF32000_2008.pdf
I need xref table from pdf file with Cross-Reference Streams.
This is pdf file
https://ufile.io/q77el
Part of pdf file:
startxref
22827515
%%EOF
This is this part:
6628 0 obj
<<
/W [1 4 1]
/Info 1 0 R
/Root 2 0 R
/Size 6629
/Type /XRef
/Filter /FlateDecode
/Length 3996
/DecodeParms <<
/Columns 6
/Predictor 12
>>
>>
stream
xÚí]{|ŽåŸç=ïÝf6LNIŒ³ŒeHŽ;ÙæÜÁ!D¥ƒèWé...
endstream
I found this text, use function gzucompress and have this
$a = gzuncompress(substr($match[2][0],1,-1));
0200 0000 0000 ff02 0200 0000 0301 02ff
0000 000c 0002 0000 000f 7e00 0201 0000
f176 0102 ff00 0000 c2ff 0201 0000 003e
0202 0000 0000 0001 0200 0000 0000 0102
0000 0000 0001 0200 0000 0000 0102 0000
0000 0001 0200 0000 0000 0102 ff00 000d
3bf8 0201 0000 f3c5 0902 0000 0000 0001
0200 0000 0000 0102 0000 0000 0001 0200
0000 0000 0102 0000 0000 0001 0200 0000
0000 0102 0000 0000 0001 0200 0000 0000
txt file
But what this mean?
I see /W [1 4 1] means that i need to split the string into 3 parts : 1 byte 4 bytes 1 byte
02 00000000 00
ff 02020000 00
03 0102ff00 00
00 0c000200 00
But this does not work.
please, tell me what my next step. Thank you!
Answer - predictor information.
/Columns 6 - mean that splin on n+1
/Predictor 12 - mean that this is png algoritm
I have hex strings that I need to convert to Base-2 binary strings, but I cannot get Impala to perform consistently.
E.g.
I would expect this statement:
select conv('0020008000',16,2) union
select conv('000006040A',16,2);
To return:
0000 0000 0010 0000 0000 0000 1000 0000 0000 0000
0000 0000 0000 0000 0000 0110 0000 0100 0000 1010
However, instead it's returning:
0000 0000 0010 0000 0000 0000 1000 0000 0000 0000
1100 0000 1000 0001 010
The 1st HEX value is converted correctly, but the 2nd is missing the first 21 digits (all zeros).
Can anyone explain why this is happening and how I can fix this behaviour?
Impala/Hive treats multiple leading zeros as redundant and trims them. I'm not sure if this behavior can be toggled on/off. I worked around it using lpad function.
Trying to get first time Magenta installation to generate a playable midi.
After upgrading bazel on OSX to ‘Build label: 0.2.3’ Magenta
works with this ‘example.mid’ input midi placed in a subdirectory.
tmp3/example.mid
4d54 6864 0000 0006 0001 0002 00dc 4d54 726b 0000 0019 00ff 5804
0402 1808 00ff 5103 03d0 9000 ff59 0200 0001 ff2f 004d 5472
6b00 0000 4000 c000 0090 3c64 8151 3c00 0b3e 6481 513e 000b 4064
8151 4000 0b41 6481 5141 000b 4364 8151 4300 0b45 6481 5145
000b 4764 8151 4700 0b48 6481 5148 0001 ff2f 00
after running
bazel build magenta:convert_midi_dir_to_note_sequences
then
mkdir out3
touch out3/newexample.mid
./bazel-bin/magenta/convert_midi_dir_to_note_sequences \
--midi_dir=/Users/user/Downloads/magenta-master/tmp3 \
--output_file=/Users/user/Downloads/magenta-master/out3/newexample.mid \
--recursive
you get
out3/newexample.mid
2101 0000 0000 0000 072b 7cb0 0a36 2f69 642f 6d69 6469 2f74 6d70
332f 3364 3864 3537 3835 6634 3838 6666 6438 3837 3566 3130
6131 3238 3538 6336 6636 6332 3135 3230 3638 120b 6578 616d 706c
652e 6d69 641a 0474 6d70 3320 dc01 2a04 1004 1804 3200 3a09
1100 0000 0000 006e 4042 0d08 3c10 6421 6666 6666 6666 ce3f 4216
083e 1064 1900 0000 0000 00d0 3f21 3333 3333 3333 df3f 4216
0840 1064 1900 0000 0000 00e0 3f21 9999 9999 9999 e73f 4216
0841 1064 1900 0000 0000 00e8 3f21 9999 9999 9999 ef3f 4216
0843 1064 1900 0000 0000 00f0 3f21 cdcc cccc cccc f33f 4216
0845 1064 1900 0000 0000 00f4 3f21 cccc cccc cccc f73f 4216
0847 1064 1900 0000 0000 00f8 3f21 cccc cccc cccc fb3f 4216
0848 1064 1900 0000 0000 00fc 3f21 cccc cccc cccc ff3f 49cc
cccc cccc ccff 3f13 5fbf 34
but the music file doesn’t play. Even if you add ‘ff2f 00’ (common suggestion) to the end.
How can you make this resulting file play in a player such as Quicktime 7? Any ideas?
We've recently added a model that you can train to generate new sequences. Have a look at https://github.com/tensorflow/magenta/blob/master/magenta/models/basic_rnn/README.md.
Thanks!
I'm trying to interpret a system crash that is repeatable, but but not that often. I believe it has do with a third party driver and a optical scanning device. I'm not sure if the driver for scanning device is causing the hang if it's bringing something out in a USB driver that causes the hang or if it's something totally different.
I'm not a driver developer, so I'm fumbling my way through the crash dump while reading the Linux Kernel Crash Book located here - http://rogunix.com/docs/Reversing&Exploiting/Linux_Kernel_Crash_Book.pdf .
I was able to setup a debug kernel with the kexec tools to produce a vmcore. With crash is see the PANIC: "Oops: 0000 [#1]" (check log for details) and in the logs is see the BUG: unable to handle kernel paging request at virtual address 00100100.
Can you help me interpret more of the dump so I can go back to the developer of the driver and tell them the findings or can you tell me is not the driver at all.
Here's more from the dump. Many thanks in advance.
KERNEL: /usr/lib/debug/lib/modules/2.6.18-194.el5debug/vmlinux
DUMPFILE: /root/kernel/vmcore_12032014
CPUS: 4
DATE: Sat Oct 20 16:51:55 2001
UPTIME: 00:03:55
LOAD AVERAGE: 0.79, 0.83, 0.38
TASKS: 128
NODENAME: 3232A
RELEASE: 2.6.18-194.el5debug
VERSION: #1 SMP Fri Apr 2 16:56:41 EDT 2010
MACHINE: i686 (1800 Mhz)
MEMORY: 2 GB
PANIC: "Oops: 0000 [#1]" (check log for details)
PID: 0
COMMAND: "swapper"
TASK: c069d460 (1 of 4) [THREAD_INFO: c075f000]
CPU: 0
STATE: TASK_RUNNING (PANIC)
crash> bt
PID: 0 TASK: c069d460 CPU: 0 COMMAND: "swapper"
#0 [c080cdb0] crash_kexec at c044a386
#1 [c080cdf4] die at c04065c3
#2 [c080ce24] do_page_fault at c062d1b7
#3 [c080ce5c] error_code (via page_fault) at c0405bc3
EAX: f7c7de2c EBX: 000ffaec ECX: 00000000 EDX: f4282e8c EBP: f7c665a0
DS: 007b ESI: f7c7ddf8 ES: 007b EDI: c080cea4
CS: 0060 EIP: c05a2ef2 ERR: ffffffff EFLAGS: 00010012
#4 [c080ce90] hiddev_send_event at c05a2ef2
#5 [c080cea0] hiddev_report_event at c05a2fcc
#6 [c080cec8] hid_input_report at c05a0fc3
#7 [c080cf1c] hid_irq_in at c05a261d
#8 [c080cf2c] usb_hcd_giveback_urb at c05964b6
#9 [c080cf3c] uhci_giveback_urb at f883f618 [uhci_hcd]
#10 [c080cf58] uhci_scan_schedule at f883fc14 [uhci_hcd]
#11 [c080cfa4] uhci_irq at f884163d [uhci_hcd]
#12 [c080cfc4] usb_hcd_irq at c0596f9b
#13 [c080cfcc] handle_IRQ_event at c0454d5f
#14 [c080cfe4] __do_IRQ at c0454e2d
--- <hard IRQ> ---
#0 [c075ff80] do_IRQ at c040761f
#1 [c075ff98] common_interrupt at c0405a28
EAX: 00000000 EBX: c075f008 ECX: 00000000 EDX: 00000000 EBP: 00000020
DS: 007b ESI: c06440f8 ES: 007b EDI: ca138790
CS: 0060 EIP: c0403d0a ERR: ffffff4e EFLAGS: 00000246
#2 [c075ffcc] mwait_idle at c0403d0a
#3 [c075ffd4] cpu_idle at c0403cc4
crash> log
Scan: First buffer received = 0x6
Scan: Last packet of command transfer = 6 Command size 6
Scan: 0x2 0x51 0x88 0x80 0x81 0x3
Scan: Read data present
Scan: IOCTL_PS3_PEAK_MSG
Scan: In scanner_read Scan: Copied 1 chunks of data to user space
usb 4-1: new full speed USB device using uhci_hcd and address 3
usb 4-1: configuration #1 chosen from 1 choice
pl2303 4-1:1.0: pl2303 converter detected
usb 4-1: pl2303 converter now attached to ttyUSB0
BUG: unable to handle kernel paging request at virtual address 00100100
printing eip:
c05a2ef2
*pde = 76330067
Oops: 0000 [#1]
SMP
last sysfs file: /devices/pci0000:00/0000:00:1d.2/usb4/4-1/bConfigurationValue
Modules linked in: vfat fat scan_drv_scanner(U) xt_limit xt_tcpudp xt_state ip_conntrack nfnetlink iptable_filter ip_tables x_tables loop dm_mirror dm_multipath scsi_dh video backlight sbs power_meter hwmon i2c_ec dell_wmi wmi button battery asus_acpi ac lp joydev snd_hda_intel snd_seq_dummy sg snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc parport_pc serio_raw snd_hwdep parport pl2303 snd soundcore i2c_i801 usbserial r8169 i2c_core mii pcspkr dm_raid45 dm_message dm_region_hash dm_log dm_mod dm_mem_cache usb_storage ata_piix libata sd_mod scsi_mod ext3 jbd uhci_hcd ohci_hcd ehci_hcd
CPU: 0
EIP: 0060:[<c05a2ef2>] Tainted: G VLI
EFLAGS: 00010012 (2.6.18-194.el5debug #1)
EIP is at hiddev_send_event+0x65/0x95
eax: f7c7de2c ebx: 000ffaec ecx: 00000000 edx: f4282e8c
esi: f7c7ddf8 edi: c080cea4 ebp: f7c665a0 esp: c080ce94
ds: 007b es: 007b ss: 0068
Process swapper (pid: 0, ti=c080c000 task=c069d460 task.ti=c075f000)
Stack: f7cbba78 ca3ec000 c080cebc c05a2fd1 00000001 00000001 ffffffff 00000000
00000000 00000000 00000005 f7cc857c c075ff9c c05a0fc8 f7c57348 00000002
00000002 00000046 c06cbfb0 00000001 ca3ec000 f7cca001 f7cbba78 00000046
Call Trace:
[<c05a2fd1>] hiddev_report_event+0x4b/0x52
[<c05a0fc8>] hid_input_report+0x99/0x399
[<c05a2622>] hid_irq_in+0x49/0xcc
[<c05964b9>] usb_hcd_giveback_urb+0x28/0x53
[<f883f61d>] uhci_giveback_urb+0x104/0x12b [uhci_hcd]
[<f883fc19>] uhci_scan_schedule+0x4f0/0x76b [uhci_hcd]
[<f8841642>] uhci_irq+0x118/0x12e [uhci_hcd]
[<c0596f9e>] usb_hcd_irq+0x23/0x50
[<c0454d61>] handle_IRQ_event+0x3e/0x8a
[<c0454e32>] __do_IRQ+0x85/0xda
[<c0454dad>] __do_IRQ+0x0/0xda
[<c040761f>] do_IRQ+0xa4/0xd1
[<c0405a2d>] common_interrupt+0x25/0x2c
[<c0403d0a>] mwait_idle+0x2a/0x3d
[<c0403cc6>] cpu_idle+0xa4/0xbe
[<c0764a22>] start_kernel+0x39e/0x3a6
=======================
Code: b9 01 00 02 00 ba 1d 00 00 00 40 83 e0 3f 89 83 00 06 00 00 8d 83 0c 06 00 00 e8 93 ac ee ff 8b 9b 14 06 00 00 81 eb 14 06 00 00 <8b> 83 14 06 00 00 0f 18 00 90 8d 93 14 06 00 00 8d 46 34 39 c2
EIP: [<c05a2ef2>] hiddev_send_event+0x65/0x95 SS:ESP 0068:c080ce94
Updated Kernel Tested
I have since updated to the latest CentOS 5.5 released kernel (2.6.18-371.6.1), but still got a kernel panic. However this time the panic occured on the command "khubd" and not on "swapper". I was able to capture the dump and below I have provided what I hope is relevant information to pinpoint this problem. Is it a bug in the kernel or something in the driver?
KERNEL: /usr/lib/debug/lib/modules/2.6.18-371.6.1.el5debug/vmlinux
DUMPFILE: /root/kernel2/HWID-2277-31032014/vmcore
CPUS: 4
DATE: Mon Mar 31 12:50:25 2014
UPTIME: 2 days, 19:29:28
LOAD AVERAGE: 0.07, 0.09, 0.02
TASKS: 181
NODENAME: 32277
RELEASE: 2.6.18-371.6.1.el5debug
VERSION: #1 SMP Wed Mar 12 22:29:36 EDT 2014
MACHINE: i686 (1800 Mhz)
MEMORY: 2 GB
PANIC: "Oops: 0000 [#1]" (check log for details)
PID: 126
COMMAND: "khubd"
TASK: ca2fc5b0 [THREAD_INFO: f7fb2000]
CPU: 3
STATE: TASK_RUNNING (PANIC)
crash> bt
PID: 126 TASK: ca2fc5b0 CPU: 3 COMMAND: "khubd"
#0 [f7fb2dfc] crash_kexec at c044da51
#1 [f7fb2e40] die at c0406649
#2 [f7fb2e70] do_page_fault at c0639449
#3 [f7fb2eb0] device_del at c057053e
#4 [f7fb2efc] device_del at c0570552
#5 [f7fb2f10] device_unregister at c0570669
#6 [f7fb2f18] usb_remove_ep_files at c05a3dac
#7 [f7fb2f38] usb_remove_sysfs_dev_files at c05a39d6
#8 [f7fb2f44] usb_disconnect at c059db59
#9 [f7fb2f58] hub_thread at c059e663
#10 [f7fb2fcc] kthread at c0439ef6
#11 [f7fb2fe4] kernel_thread_helper at c0405e0d
crash> log (truncated)
Scan: no error - In command_callback
Scan: In command_callback
Scan: First buffer received = 0x2a
Scan: Last packet of command transfer = 42 Command size 42
Scan: 0x2 0x44 0x20 0x54 0x65 0x73 0x74 0x20 0x4d 0x65 0x73 0x73
Scan: Read data present
Scan: IOCTL_PS3_PEAK_MSG
Scan: In scanner_read Scan: Copied 1 chunks of data to user space
Scan: IOCTL_PS3_SCANNER_COMMAND Busy slots = 0x0 Total_slots = 0x8 Busy image slots = 0x0
Scan: 0x2 0x38 0x3 0x4
Scan: In write_callback status = 0x0
Scan: In image_callback
Scan: Urb status = 0xffffffb9 Urb length = 0x0
Scan: In image_callback_fun - lost connection to scanner.
Scan: urb set to re-submit
Scan: In command_callback
Scan: Urb status = 0xffffffb9 Urb length = 0x0
Scan: In command_callback_fun - lost connection to scanner.
Scan: urb set to re-submit
usb 1-6: USB disconnect, address 11
BUG: unable to handle kernel paging request at virtual address 6b6b6b93
printing eip:
c04bd310
*pde = 00000000
Oops: 0000 [#1]
SMP
last sysfs file: /devices/pci0000:00/0000:00:1d.7/usb1/1-6/bConfigurationValue
Modules linked in: vfat fat pdi_ps3_drv_scanner(U) xt_limit xt_tcpudp xt_state ip_conntrack nfnetlink iptable_filter ip_tables x_tables loop dm_mirror dm_multipath scsi_dh video backlight sbs power_meter hwmon i2c_ec dell_wmi wmi button battery asus_acpi ac lp joydev snd_hda_intel snd_seq_dummy sg snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer parport_pc snd_page_alloc snd_hwdep snd parport tpm_tis tpm soundcore r8169 tpm_bios i2c_i801 serio_raw pcspkr pl2303 usbserial mii i2c_core dm_raid45 dm_message dm_region_hash dm_log dm_mod dm_mem_cache usb_storage ata_piix libata sd_mod scsi_mod ext3 jbd uhci_hcd ohci_hcd ehci_hcd
CPU: 3
EIP: 0060:[<c04bd310>] Tainted: G -------------------- VLI
EFLAGS: 00010202 (2.6.18-371.6.1.el5debug #1)
EIP is at sysfs_hash_and_remove+0x18/0x103
eax: 6b6b6b6b ebx: f4be5bf4 ecx: c0570543 edx: 6b6b6b6b
esi: f4be5b0c edi: f3cd936c ebp: f3cd93c4 esp: f7fb2ee0
ds: 007b es: 007b ss: 0068
Process khubd (pid: 126, ti=f7fb2000 task=ca2fc5b0 task.ti=f7fb2000)
Stack: f4be5c50 6b6b6b6b f764d16c f4be5bf4 f4be5b0c f3cd936c f3cd93c4 c0570557
f4be5b0c f3cd93a0 f3cd936c f7c8da2c c057066e f7fb2f28 c05a3db1 f7fb2f28
c06827a6 00000000 305f7065 c06d0030 f3cd936c f3cd93c4 c05a39db f3cd96cc
Call Trace:
[<c0570557>] device_del+0x5c/0x16b
[<c057066e>] device_unregister+0x8/0x10
[<c05a3db1>] usb_remove_ep_files+0x53/0x75
[<c05a39db>] usb_remove_sysfs_dev_files+0xf/0x6c
[<c059db5e>] usb_disconnect+0xa7/0xe0
[<c059e668>] hub_thread+0x327/0x987
[<c0439ed9>] kthread+0xa1/0xec
[<c0439fab>] autoremove_wake_function+0x0/0x2d
[<c059e341>] hub_thread+0x0/0x987
[<c0439ef8>] kthread+0xc0/0xec
[<c0439e38>] kthread+0x0/0xec
[<c0405e0f>] kernel_thread_helper+0x7/0x10
=======================
Code: 8b 40 24 8b 40 40 c3 8b 40 14 8b 00 c3 8b 40 14 8b 00 c3 55 57 56 53 83 ec 0c 85 c0 89 44 24 04 89 14 24 0f 84 e5 00 00 00 89 c2 <8b> 40 28 85 c0 0f 84 d8 00 00 00 8b 52 70 05 90 00 00 00 89 54
EIP: [<c04bd310>] sysfs_hash_and_remove+0x18/0x103 SS:ESP 0068:f7fb2ee0